HIT Think

Patient/Physician Portals, a Stepwise Approach – Part 2

Register now

As you may recall from last month’s article, in the world of health care I.T., there is a focus on portals. These portals are built to meet Meaningful Use Sections 170.304(h) and 170.306(d), which provide patients with the ability to access clinical summaries, as well as health information. 

Portals, if well built, facilitate communications with patients and doctors using a common set of data, and they put the data into a more understandable context for the doctor. Moreover, the use of portals increases the amount of meaningful data that’s available within the portals.  This includes leveraging analytics built around local and remote big data systems that provide the ability to validate diagnostics and treatments against massive amounts of historical treatment and outcome data. 

Last month we outlined the first few steps, including:

Step 1:  Understand the Data.

Step 2:  Logically Group the Data.

Step 3: Define Interfaces and Access Approaches.

Step 4:  Define the Analytics Services. 

Moving on:

Step 5:  Define service governance and service security.

Service governance is the ability to place policies around services, as we defined in the previous steps, to control access to those services.  This includes who can access the services, what they can do with the services, and any usage parameters that should be set.

Service governance technology comes in many flavors, due to the number of vendors in that space and how that vendor defines governance. There are no de facto standards as to what run-time service governance needs to be, but there are certain patterns that are emerging.

Run-time service governance typically includes:

    Service discovery - the process of finding, analyzing, and detailing out an existing service and the use of a policy to govern that service.  

    Service delivery - the process of moving services from development to execution or production, either on-premise, or in the clouds.   

    Security - the functions around protection of the services that are managed, and enforcement of the policies.  In the world of portals that are service-based, which is what we’re talking about here, this means federated identity-based security. This means assigning an identity to all services, devices, humans, data, etc. Then, define who is authorized to do what, and with what other resources. Again, you need to consider any regulations that are germane to the information being leveraged by the portal. 

    Setting and maintaining appropriate service levels - makes sure all of the services execute per the service agreements and preset levels.   

    Managing errors and exceptions - a feature where any errors and exceptions that occur are captured, analyzed, and perhaps recovered from automatically.  

    Enabling online upgrades and versioning - the process of placing new services and/or polices into service, and controlling the process around the upgrades made to services and/or policies, and controlling how services and/or polices are versioned.   

    Service validation - the feature of the governance technology that validates that the services are “well formed,” and prepared to go into production.  

    Auditing and logging - the governance technology that will track the execution of the services and the policies, including what they do, when they do it, and whom they do it with. Again, regulations come into play here in terms of the required auditing capabilities required.   

    Step 7:  Define/build the user interface

    In this step there is a design and development aspect to defining and building a user interface. In reality, there are any number of technologies you can leverage, including technology that is specifically design for the development of healthcare portals, or general use portals.   

    The type of technology you leverage depends upon the humans and devices you’re looking to externalize the data to. Thus, your selection of technology is going to be very different, depending upon many patterns of use.   

    A few helpful hints around defining and building a user interface for a patient/physician portal: Look at the development and the configuration aspects of your portal development technology. You should have an easy time building solutions, as well as changing solutions moving forward. You’re going to be doing both.  

    Look at the ability for the portal to consume different types of services, such as REST-based Web Services. They should be open and extensible.   

    Design with human factors in mind. The ability for humans, patients and doctors to leverage this thing will determine its success. Thus, make sure you do some focus groups, or have other ways to gather feedback from those who will use the portal.   

    Step 8:  Define operations  

    Finally, define operations. How will the portal function over time? Who will maintain it? How they will maintain it?  

    Items to consider include:  

    • Resiliency, or disaster recovery strategy and mechanism.Scaling the portal as the number of users increase.
    • Physical security. 
    • Performance management. 
    • Maintenance schedule.  

    That’s it. Follow these steps, and a well-defined, well-built, and operationally successful patient and physician portal is in your future. While I could not cover each and every detail, this is a good general approach.   
    David Linthicum is an SVP with Cloud Technology Partners, a cloud computing consulting and advisory firm. David’s latest book is "Cloud Computing and SOA Convergence in Your Enterprise, a Step-by-Step Approach." His Web site is www.davidlinthicum.com/


    For reprint and licensing requests for this article, click here.