archive-org.com » ORG » M » MARKLE.ORG

Total: 1237

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • T6 | Markle | Advancing America's Future
    may be categorized as belonging to certain standard architectural patterns called service gateway and service interface 13 The service gateway is an agent encapsulating the details of communicating with remote web services and enabling legacy applications to consume web services The service interface is a façade encapsulating the legacy application by overlaying a web services wrapper and enabling remote systems to communicate to it Technically RLS can be implemented as a composition of the above services to provide services to remote applications over the globally available Internet But in recognition of the practical constraints of legacy clinical systems the architecture also provides guidance on connecting clinical systems to RLS This may be accomplished through a web service interface as listed above and Adaptors Facilitate connections to clinical systems and databases through database interfaces or custom API The message transformation web services interface and adaptor components are the key infrastructural service for the interoperation of disparate clinical systems Essentially these infrastructure services expose the RLS patient index as well as clinical systems as web services and enable them to consume web services Thus connectivity in the network is established using platform and payload agnostic open standards 4 3 Gateway Services Following the principle of deploying applications as aggregations of loosely coupled services the infrastructure services listed above could be bundled to form a composite Clinical Data Exchange CDX Gateway for the clinical systems to interoperate with each other By designing the CDX Gateway to support general purpose secure and reliable messaging between clinical systems it serves as the standards based on ramp to a health information network The RLS may be realized as the orchestration of the following two service compositions which may be considered as the business service and infrastructure service respectively Patient Index Central service that maintains the community patient index and a registry of clinical systems with routing information to direct service requests and responses to appropriate end points CDX Gateway Distributed service that interfaces to each network node converts from the legacy data messaging format to the standard message if needed and communicates to other gateways in the network through Web services The CDX Gateway needs to be a small footprint low cost service that can be deployed in participant institutions with minimal customization to interface with disparate clinical systems on one side and to other Gateways via the public Internet on the other A CDX Gateway is also deployed at the RLS to support messaging with the other network nodes exposing the Patient Index to external systems through this common utility component Figure 7 RLS Distribution of Components Such a gateway serves as a general purpose utility to support medical records retrieval as well as RLS communication services Users acquire patient record locations pointers from the RLS and access data from multiple clinical data sources as shown in Figure 7 Note the parallels with the conceptual architectural vision in Figure 5 As may be seen from Figure 7 communication between all network nodes is through the CDX Gateway at that node In addition presentation and business services would be required for the user interface functionality of the RLS patient search criteria entry and selection of patient record locations to query Online users would log into the CDX Gateway co located with the clinical system to which they are affiliated and access RLS services The collection of clinical systems that hold patient medical information at each network node is called the Electronic Health Record EHR in the figure and in the following discussions In the figure an online interaction is shown at the CDX Gateway at EHR 1 whence the patient lookup request is made to the RLS The other nodes EHR 2 and EHR 3 serve as clinical data sources Data retrieval from backend systems at the clinical data sources is done through the adaptor services in the CDX Gateway The data sources publish patient index updates to the RLS also via the CDX Gateway services at those nodes Although not shown in the figure online users at EHR 2 and EHR 3 can also access patient lookup services at RLS and other clinical data exchange services RLS receives service requests through a CDX Gateway at its location RLS needs an administrative user interface to manage the application which would be the responsibility of the presentation and business services in the gateway at the RLS The gateway based architecture provides significant flexibility and scalability More clinical data sources could be added by deploying a CDX Gateway at that location and customizing adaptors to connect with the clinical system there The Gateway transforms local message formats into standard ones and manages their secure reliable communication to other Gateways In general the expectation is that CDX Gateways that are approximate clones of each other would simplify deployment configuration and administration of this distributed service The CDX Gateway thus serves as a general utility service that may be plugged in at different EHR locations In addition the CDX Gateway serves as an infrastructure component which realizes the common framework standards in a packaged form CDX Gateway application architecture is based on a multi tiered pattern of presentation business and data and integration tiers The integration tier is the service that interfaces with clinical systems data sources at the backend and communicates with remote Gateways through orchestrated web services at the other Gateways also include capability to serve as messaging intermediaries This is a side effect of implementation of WS standards which include WS Security and WS Addressing in the CDX Gateway that enables secure reliable SOAP intermediary functionality A more detailed view of the CDX Gateway and its interaction with other gateways is shown in Figure 8 The distribution of functionality between a pair of communicating Gateways is flexible dependent on the capabilities available at the clinical systems at each network node The architecture shown in Figure 8 depicts the two EHR nodes playing distinct roles healthcare practitioner and clinical data source There are no backend clinical systems at the healthcare practitioner node and the presentation and business services are not deployed at the clinical data source Within the gateway the message handling clinical system adaptors and web service interfaces are shown encapsulated in an Integration Broker service It is expected that each CDX Gateway deployment initially requires significant custom localization of the Integration Broker service to cater to EHRs that do not conform to prescribed standards Over time clinical systems are expected to develop standard Web service interfaces This would reduce the processing requirements of CDX Gateway and would enable lighter weight Gateways to be directly pluggable into the data sources CDX Gateways communicate with each other using Web services protocol WSDL and SOAP over the standard HTTP SSL transport protocol Gateways could extend in future to adopt alternate transport protocol such as Secure FTP for batch file transfer and SMTP using industry standard S MIME encryption for email Figure 8 Gateway based interaction in a health information network 4 4 RLS Based Networks The RLS based network strategy may be summarized as Web service enabling clinical systems Nodes communicate with each other through HL7 or other domain specific standard format messages wrapped in SOAP envelopes over HTTPS transport Such a peer to peer clinical information network is shown in Figure 9 Figure 9 Network of clinical systems communicating peer to peer The diagram shows diverse ways of deploying CDX Gateway to connect health information network participants to RLS While clinical systems routinely send patient index updates to the RLS users connect to RLS via their local clinical system to query patient record locations patient lookup Patient lookup can also be done in a non interactive manner through request response messages exchanged between gateways at EHR locations and the RLS In addition a user can query RLS from anywhere on the Internet using only a thin viewer This mode requires the CDX Gateway at the RLS location to serve up the user interface and business logic much as a gateway at an EHR location would Since CDX Gateways are clones of each other this can be achieved by configuring the services in the RLS gateway appropriately In addition it should be noted that the gateway service could play the role of a data cache The data storage layer in the CDX Gateway see Figure 8 could potentially hold a data repository into which clinical data is replicated from the EHR and made available to network access Indeed it is thought that clinical enterprises would likely prefer to have database queries be directed at such a proxy cache rather than exposing operational systems to remote queries over a health information network 4 5 Regional and National Network Support Current thinking on national health information network envisages interconnected exchanges hosted by Regional Health Information Organizations RHIOs Such a network of networks is shown in Figure 10 Figure 10 Network of RLS based networks potentially used by RHIO The RLS architecture itself presumes no regional dimension the scoping function of the RLS is the community master patient index that maintains pointers to patient records in distributed EHRs in the community However RLS clearly is a candidate for the central coordinating service of a RHIO network In regards to inter RHIO communication it is easy to see that the RLS could also play a key role in routing and coordination of services across RHIOs Some RHIOs may be based upon a centralized data repository as determined by regional policy considerations as well as legacy architectural considerations others are decentralized Both models as well as intermediate ones are supported by the proposed NHIN architecture Using a common framework based on open standards and common policies allows a RHIO to be agnostic about the architecture of another RHIO The service oriented CDX Gateway architecture also enables a degree of flexibility in implementation styles and operational configuration as discussed further in the following section pagebreak 5 Process View The RLS application is a collection of loosely coupled interoperable services and is itself a service that can be invoked by external consumers Components that are distributed across network nodes communicate via XML messages using Web service standards primarily SOAP and WSDL Additional Web service standards may be used to support reliable messaging error handling and security The essential RLS functions to fulfill the patient lookup and publish patient index use cases are realized through distributed processing of the RLS services as described below 5 1 Patient Lookup and Peer to Peer Medical Records Retrieval The patient lookup process may be visualized as shown in the simplified communication diagram in Figure 11 where the flow of information and messages between the distributed processing components may be tracked through the sequence numbers provided Figure 11 Patient Lookup with RLS and Medical Records Retrieval through CDX Gateways The interaction diagram illustrates the use of gateways to manage all communications between network nodes Gateways also encapsulate presentation business and data access services thereby providing a full application stack for flexible implementation of RLS services For example while the patient lookup is shown as an interactive process it could as well be transacted offline in batch mode 5 2 Patient Index Publish The patient publish process is simpler in that it is a notification type background interaction The initiating message is triggered by a registration event at the clinical data source and essentially serves to update the patient index with details of the patient whose record has been updated i e added revised cancelled or merged with another patient record in the clinical data source This interaction is shown in Figure 12 Figure 12 Patient Publish into RLS Patient Index Typically patient registrations are maintained in ADT systems in hospital environments An ADT event message is broadcast to the other ancillary systems in the hospital such as laboratory radiology transcription etc The RLS patient publish message is generated by tapping off the same broadcast ADT message requiring minimal changes to existing hospital systems While this message is notification only a basic exception handling capability needs to be built where errors in posting the update to the RLS patient index are communicated to the data source If the error does not require reentry of the ADT transaction a mechanism to fix the data problem and resend the message to RLS needs to be built in the clinical system or interface engine 5 3 Centrally Mediated Medical Records Retrieval The scenario shown in Figure 11 represents a federated architecture supporting peer to peer clinical data exchange Alternate scenarios exist such as a hub and spoke model where patient medical requests are mediated by a central gateway service The collaboration diagram below demonstrates how a user could log in directly to a central CDX Gateway in this case co located with RLS and perform the same function Figure 13 Centrally Mediated Patient Lookup and Record Retrieval Hosted Gateway Note that the healthcare practitioner is shown as logging directly into the gateway at the RLS location and executing the patient lookup query directly on RLS This is another variation of the use of the CDX Gateway and demonstrates the implementation flexibility a standard gateway utility based network architecture allows 5 4 Central Medical Records Aggregation Yet another processing model would remove the need for a two step process altogether and have the patient lookup request be combined with a medical records request which the CDX Gateway at the RLS would orchestrate Such a scenario is shown in Figure 14 Figure 14 Patient Lookup and Records Retrieval In One Step This interaction pattern is more appropriate for unattended RLS usage where a clinical system collects remote patient records and has them ready for review by a healthcare practitioner at later time The orchestration process in the CDX Gateway is now more complex and should implement workflow processes of the healthcare practitioner including selection of appropriate medical records to retrieve from various sources Other supplementary processes include the need for secure information sharing and the establishment of contracts between the RLS and the various clinical data sources that would share patient medical records with each other In both of these situations RLS serves as a trusted intermediary and reduces the need for the many to many relationships between the various clinical data sources The secure messaging process is described below 5 5 Security Processes RLS needs a security framework to authenticate users authorize access to specific services and ensure confidentiality and integrity of messages The implementation of security across a disparate distributed computing network is optimally effected through a federated identity management architecture where each user is authenticated by an assigned node that vouches for the user to other nodes Federated security architecture is complex and considered beyond the scope of the current release of RLS RLS uses a simpler model that can be extended to a federated architecture in later releases A distributed authentication authorization architecture that is based on overlapping trust relationships is shown in Figure 15 Users identity and credentials are maintained at the gateway that they log in to Gateways are within the clinical enterprise domain and may be integrated with the enterprise security infrastructure to support single sign on for users Gateways are in a trust relationship with other gateways and authenticate each other through server side certificates An authentication authorization assertion is communicated in the SOAP message along with the user identifier string for audit purposes Secure Socket Layer SSL is a session layer protocol for sending encrypted information over HTTP SSL provides an encrypted channel with confidentiality integrity and one way or two way authentication SSL is used to secure messages between gateways in the RLS based network Gateway authentication may be provided by server side digital certificates Figure 15 RLS Authentication Service Over the longer term CDX Gateways should leverage WS Security the emerging security standard for SOAP messaging where different security tokens are embedded in SOAP Headers The XML Signature and XML Encryption standard provides a platform neutral approach to message level authentication confidentiality integrity and non repudiation Security Assertion Markup Language SAML provides a technology neutral way to exchange security information using XML to communicate authentication authorization and other user attribute information SAML also allows interoperation across different platforms such as J2EE NET and CORBA WS Security supports the use of a SAML token in the SOAP header The distributed authentication process implemented in the RLS prototype is shown in more detail in Figure 16 Figure 16 Authentication Mechanisms for Patient Lookup and Medical Records Retrieval 5 6 Messaging Patterns RLS defines contracts to govern message exchanges that implement services These message exchange patterns or message scenarios are the basic transactions that Web services are designed around The logical components and services described in the previous section may be considered as the plumbing or the Common Framework for the health information exchange The framework is capable of supporting various message scenarios that support multiple use cases There are four common messaging interaction patterns that characterize service oriented scenarios One way or fire and forget messaging involves the sending of a message from requester to provider with no acknowledgement expected Request Response implies that a response message is generated for every request received by the provider Notification may be considered a mirror image of the one way pattern where the provider sends a one way message to the requester Solicit response is the reverse of request response in that the service provider sends a solicitation for a request to a requester The contract between service provider and requestor is defined using a standard XML based language called Web Services Description Language WSDL Note that the WSDL 1 1 messaging terminology above have been superseded in the WSDL 2 0 specifications with more precise names these do not have a material impact on the RLS specifications and are not used 14 The message scenarios supported by RLS prototype are listed below Table 2 List of Messaging Interactions Supported by RLS Prototype Name Triggering Event Interaction Type Sender Receiver Receiver Responsibility 1 Lookup patient locations Practitioner receives consent from patient to retrieve medical history Request Response Practitioner via CDX Gateway RLS Search master patient index Match patients using linking algorithm Return list of patient locations clinical systems and MRN 2 Publish patient index Registration of new patient into Clinical System Patient consent is pre requisite Notification Clinical System via CDX Gateway RLS Patient basic demographics and MRN as maintained in the Clinical System used to update CMPI 3 Message logging Passing of message through gateway One way CDX Gateway RLS Insert log message into standard format logging database 4 Exception logging Error condition in message processing One way CDX Gateway RLS Insert error message into standard format logging database and notify Administrator 5 Retrieve medication history records Authorized practitioner submits request Patient consent is pre requisite Request Response Practitioner via CDX Gateway Clinical System via CDX Gateway Return requested medication history list in a standard message format Each message scenario assumes that an error message SOAP Fault is returned by the receiver to the sender if the message results cannot be parsed or results in any application error The flow of logic across the different service layers in the RLS CDX Gateway solution architectures is shown as sequence diagrams in Figure 17 and Figure 18 where the application process logic may be visualized as a series of messages exchanged between application services The services oriented architecture is realized through implementation of messaging between application components as shown here Figure 17 depicts the interactions between RLS application components to provide the patient lookup service to users logging in to remote gateways Figure 17 Patient Lookup Sequence Diagram As can be see in the figure the Gateway services communicate with each other through the integration broker services The other core RLS service is that of accepting updates to patient indices from clinical data sources and applying them to the RLS CMPI This may be visualized in the sequence diagram in Figure 18 Figure 18 Publish Patient Index Sequence Diagram pagebreak 6 Implementation View This section describes how the relevant components of the RLS logical architecture are implemented While the logical and process views provide more conceptual models of RLS the implementation and deployment views relate more to the physical artifacts that make up the RLS based interoperability framework The implementation view presents a more detailed view of the organization of the static software elements of the RLS prototype than was presented in the logical view Note that implementation of systems based on the RLS architecture is to be undertaken by individual RHIOs which have significant latitude of action Each RHIO may choose implementation strategies based on their internal development methods and platform preferences This section provides only generic implementation related information and refers to the RLS prototype implementation architecture and platform for purely illustrative purposes RLS architecture is generic and platform agnostic with interoperability based on open connectivity standards such as Web services and semantic data standards such as the HL7 Reference Information Model This section also outlines the relevant standards prescribed for an RLS implementation Given that interoperability is critically dependent on the communication and data standards adopted the expectation is that each implementation adheres closely to the recommended standards and specifications More detailed guidance on implementing message format standards and specifications is provided in a separate document RLS Messaging Communication Implementation Guide 6 1 Overview RLS is a classic n tiered database application with a web browser based user interface and capability to interoperate with remote systems using open standard messaging over the Internet The key interoperability function is realized through implementing a gateway service at each node in the network that provides essential presentation business and data services and the ability to communicate with other gateways using web services and domain specific data standards The RLS application may be viewed as comprising two large grained components or service compositions Patient Index service maintains and enables access to the community Master Patient Index CMPI and maintains a community directory registry for the various clinical data sources data and message standards etc CDX Gateways provides a web service wrapper and other utility services to support message based interoperation for the RLS as well as for each clinical data source in the network The patient index service architecture essentially comprises components that provide Patient Record Linking Matching and Patient Record Search services The CMPI database contains basic patient demographic information and patient identifiers as maintained in the various clinical data sources that publish into the CMPI Each patient record is tagged with the network resolvable address of its source The unified patient view is achieved through linking matching of patient records based on demographic attributes Record matching may use deterministic exact matching of patient demographic attributes or a probabilistic algorithm which takes into account the variations in source data due to data entry anomalies The architecture implementation supports the swapping of matching algorithms by change of run time parameters CDX Gateways enable the interoperation of backend legacy clinical systems with each other and with the RLS through exchange of messages of various formats with other gateways using Web services protocols over HTTP transport secured with SSL TLS or HTTPS 6 2 Components and Layers A logical view of the RLS application architecture was presented in the section 4 A more detailed breakdown of the components of the RLS their logical groupings layers and implementation platforms used in the prototype project is shown in Figure 19 Figure 19 RLS and CDX Gateway Components and Sample Prototype Implementation Platforms The diagram shows one EHR node comprising a clinical system and a gateway connected to the RLS One may imagine many such nodes also communicating to the RLS through the Web service interface component in the Integration Broker service of the gateway CDX Gateways interface with the local clinical systems through the EHR adaptor A design objective would be to isolate and layer services such that only the adaptor components in the Integration Broker service layer would need to be customized for each site where the Gateway is deployed The service layers are independently deployable units which are orchestrated by a service broker or bus For example the security and systems management layers are shared across multiple business application services Thus all the service layers are loosely coupled and reusable Implementations of RLS may vary based on the specific needs of the site with the potential for sites to tighten coupling as necessary They may also use alternate infrastructure services e g security that conform to local standards as long as they also honor the interface standards used for RLS More details of the functionality of each of the components that comprise the service layers are provided in Table 3 Table 3 CDX Gateway Service Components Description Service Components Description Presentation Services Formats data display to meet end user interaction and display device requirements Login Enter username and password to gain access to RLS Lookup Patient Patient demographics data entry Review Select from Patient Index list Present list of potential matches of patients to demographics data entered to be selected from Request Patient Records Selection of specific patient medical records to be retrieved from source View Aggregate Records Present patient medical records received from multiple sources in common format Monitor Messages View log of messages passing through RLS Manage Access Control Policies Create and maintain access control policies Manage User Identities Create and maintain user identity information and roles to which assigned Business Application Services Key functional components that house business rules and execute business logic on clinical data to render it comprehensible to the healthcare practitioner Patient index Patient index business object Medical records aggregation Application object that merges medical records received from multiple clinical data sources Medical records request Standard application object that mediates the data request entered by users on a screen and the data access services Auditing Services Support the auditing of access to medical data using logs of all significant events in gateway operations Medication list Meds administered business object Lab Micro Radiology Laboratory microbiology radiology results business object Images and Waveforms EKG EEG graphs Radiology imaging etc Notes Reports Clinical documentation business object Visit History Patient encounters business object Problem list List of current diagnoses business object Data Management Services Manage application access to data storage and processing of data in data storage layer Isolates the business layer from the details of the data storage service Supports management of metadata about data stores and repositories in system Persistence Data Access Provide standard data access to business application services that is independent of the underlying data storage technology or database management systems Code sets and Key management Manage disparate code sets and generated keys for data imported from multiple systems Replication backup data cache management Technical data management services Support data aggregation and asynchronous data streams management Data cache for clinical data where required Data Storage Services Provide reliable secure data storage for efficient access by data management services Data Cache For storing temporary copies of data retrieved from clinical data sources for faster response to user queries This could be a significant component for pilot production implementation since it buffers the clinical data sources from external queries However there are significant business and technical issues to be resolved for clinical data caching Message store Logs and Audit Persistence mechanism for reliable messaging and for monitoring of message flow may be part of System Management Services User directory Certificates store Data store for security services layer may be part of Security Services XML Schema and metadata services Repository of message and data standards for reference both run time and design time Integration Broker Services Manages flow of messages through the Gateway that serves RLS and the clinical systems that communicate with RLS Message Queuing and Transport Provides store and forward capability and manages connection to messaging infrastructure Supports asynchronous messaging between loosely coupled services Message translation Transform message formats based on mappings Routing Orchestration Routes messages to the appropriate destination channels Web Services Interface SOAP and WSDL processing along with other WS service implementations e g reliable messaging error handling security XML Processing Serialization deserialization of messages validation of messages against XML schema and translation from one schema to another using XSLT HL7 Mapping Conversion from HL 2 x messages to RLS standard formats HL7 v3 EHR Adaptor EHR system specific component with ability to extract required medical records from EHR system MPI Adaptor Component to interface with Master Patient Indexes including CMPI SQL Replication ETL Adaptor Data movement from one data store to another includes transformation as needed and typically executed in batch bulk mode Systems Management Services Besides application management functions shown below extends over the long term to cover remote deployment configuration administration and patch application of distributed Gateway from central location Logging services Interface for application to log processing events Exception Handling Services Interface to raise and manage errors in application processing Configuration Interface to manage the configuration of the RLS application E g setting record linking matching algorithm logging levels etc Security Services Manage the implementation of security to control access to the system and protect confidentiality and integrity of data in the system User Roles Management Manage the creation updates and deletion of actors authorized to use RLS Authentication Authorization Personalization Validate that actors user or system is who what they claim to be Consent Management Manage individual patients consent to let healthcare practitioners view their medical records Policy Management Provide interface to configure and manage rules for access to healthcare data auditing and secure operation of RLS The services that make up the Patient Index Service of RLS are described in Table 4 Table 4 RLS Components Description Service Component Description Patient Index Services Maintain patient records sourced from multiple clinical systems and provide access to data Community Master Patient Index Multi enterprise Patient Index data store maintained in the RLS Patient Records Linking Indexing Identify multiple patient records pertaining to the same individual but created with potentially different attributes Patient Record Search Search for index for patients matching the demographic attributes entered by healthcare practitioner The interfaces between the application components shown are the subject of local implementation decisions The general bias of SOA based applications is to use XML messaging interfaces between components The CDX Gateway integration broker service may be used as a service bus that mediates connections between the coarse grained services that make up the SOA based application It should be recognized that a messaging interface often has a system performance overhead and that this penalty may not in some implementations be fully offset by the benefits of true loose coupling of application components In such cases implementations may choose to start with tighter RPC style interfaces between application components and migrate to SOA as performance management allows 6 3 Implementation Topology Options As shown in the section 5 there are several processing models that can be implemented with the gateway based network architecture Each gateway is an n tier application with distinct presentation application data storage and integration services This allows the functionality and data storage at each gateway service to be varied based on the degree of centralization or decentralization desired Being based on the Internet the health information network has a fully connected mesh topology at the transport and connectivity level The application and data distribution across the network nodes determine whether an interaction between nodes is server based or peer to peer In server based networks some computers clients consume services provided by others servers In a peer to peer network the computers on the network can act both as clients and servers and are referred to as peers The RLS based health information network is a hybrid with some key services record location being provided centrally while others clinical data exchange are consumed on a peer to peer basis RLS service oriented application architecture SOA and the Web service based network supports multiple application and network configurations with varying degrees of data and application distribution This derives from the fact that a loosely coupled peer to peer model offers the ability to tighten the coupling or centralize the architecture as needed by local implementations whereas a priori centralization does not offer such flexibility In effect the RLS based network leverages the strengths of the Internet where a fully connected network allows varying service topologies to be used based on requirements The RLS based network architecture seeks to find the right balance between being a potential single point of failure in the middle and reducing the processing footprint at the nodes The proposed SOA model enables the intra RLS service distribution to be adjusted and tuned for optimal performance at local regional and national scale A case for data decentralization can also be built on patient privacy protection grounds Recent security episodes and public perception suggest that the likelihood of data spills is reduced by not creating a large centralized repository of patient health information Leaving protected health information in local clinical systems and using a federated peer to peer clinical data exchange model reduces the likelihood of catastrophic data spills Where local clinical systems are accessible from the network the architecture anticipates data being cached by a hosted gateway service which would serve as a proxy for the legacy clinical system similar to an application service provider ASP model a hybrid variation on centralized services An additional consideration is the messaging architecture for inter RLS communication Given that the health information network nodes are all Web addressable each RLS sub network node could connect to a remote RLS sub network node on a peer to peer basis However as the security discussion indicates the need for each node to authenticate to each other impacts the scalability of such connectivity An intermediary bridging service is required that can also be provided by the CDX Gateway at the RLS The different implementation options are listed in Table 5 below Table 5 Implementation Topology Options Implementation Topology Description Decision Criteria Peer to peer using gateways for transport mediation and aggregation Clinical data are distributed and managed within their clinical systems Central patient registry for record location Gateways translate messages from local to network standard format Message and data aggregation at each gateway node Service oriented architecture provides maximum flexibility in linking disparate systems No single point of failure SPOF No centralized command and control Increased mediation aggregation functionality at Gateway complex distributed administration Peer to peer with gateways maintaining clinical data caches Gateways in addition to facilitating interconnectivity also serve as proxies for clinical data stores Clinical data sources maintain autonomy Operational clinical systems are not subject to unpredictable query loads from network users Data replication needs to be set up and maintained between clinical database and proxy cache Hub and spoke with distributed data sources using central mediation service for message routing While clinical data remains at network nodes messages are all routed through a central service Central service handles message and data aggregation The gateway at the RLS could serve as the central routing and mediation service Lighter weight gateways at the edges minimize network joining overhead Hub and spoke with central data repository Variation of the distributed proxy data cache wherein data from clinical data sources are moved to central data repository Gateway function is purely transport mediation Increased central data management and security overhead Reduced participation rates from clinical enterprises Very light weight distributed gateway High degree of data conformity required Inter RLS data sharing on a peer to peer basis Use Gateway service at each clinical system to communicate across RLS sub networks Sharing of information across communities needs to be independent of data distribution with the RLS sub network Trust relationships need to be built on very large scale across all nodes in all sub networks Inter RLS data sharing using a central intermediary service Use the RLS Gateway to provide intermediary services to mediate patient lookup and clinical data

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-professionals/t6 (2016-02-10)
    Open archived version from archive

  • Key Laws and Regulations | Markle | Advancing America's Future
    requires that a Covered Entity and business associate consider the potential harm of an Unauthorized Access of unsecured information in determining whether notification of such unauthorized access must be made 2 Exceptions Importantly not all Unauthorized Access to Protected Health Information rises to the level of a breach as defined under the provisions of the HITECH Act The exceptions set forth in the HITECH Act and applicable regulations include i the unintentional acquisition access or use of Protected Health Information by a workforce member or person acting under the authority of a Covered Entity or business associate made in good faith and within the scope of authority of the Covered Entity or business associate i e the workforce member or person acting on behalf of the Covered Entity or business associate 20 provided that it does not result in further unauthorized use or disclosure 21 ii an inadvertent disclosure of Protected Health Information from an authorized individual at a Covered Entity or business associate to another authorized individual at the same Covered Entity or business associate or organized health care arrangement in which the Covered Entity participates provided that it does not result in further unauthorized acquisition access use or disclosure 22 and iii a disclosure of Protected Health Information where a Covered Entity or business associate has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information 23 C Risk Assessment To determine whether such a risk of harm exists Covered Entities and business associates are required to carry out risk assessments upon discovering an Unauthorized Access of Protected Health Information If the Unauthorized Access of Protected Health Information meets the risk of harm threshold then the affected individuals must be given notice without unreasonable delay but not later than 60 days after discovery 24 Notice to affected individuals must contain a brief description of the occurrence of the breach and the types of information that were involved in the breach steps that individuals should take to protect themselves how the Covered Entity is mitigating harm and contact information for individuals to ask questions and learn additional information about the breach 25 If over 500 persons are affected in a given state media in that state must also be notified 26 Regulations also specify the elements that must be in the notification to the media 27 Notice must be provided to the Secretary of the U S Department of Health and Human Services the Secretary immediately if the breach involves 500 or more individuals If the breach is with respect to less than 500 individuals the Covered Entity may maintain a log of any such breach occurring and annually submit such a log to the Secretary documenting the breaches that occurred during the relevant year 28 D Expanded Administrative Obligations in Connection with Breach Notification Procedures Pursuant to the regulations promulgated under the HITECH Act for breach notification for unsecured Protected Health Information 45 C F R Parts 160 and 164 29 the administrative requirements that Covered Entities must fulfill under the Privacy Rule have been expanded to apply in the context of the new breach notification provisions 30 1 Mandatory Training Each Covered Entity is required to train all members of its workforce on policies and procedures with respect to the new breach notification provisions 31 2 Mandatory Training on Material Changes In addition to requiring training for all current and new employees the regulations specifically require training to be provided to each member of the Covered Entity s workforce whose functions are affected by a material change in the policies or procedures caused by the new breach notification provisions within a reasonable period of time after the material change becomes effective 32 3 Sanctions Against Workforce Members A Covered Entity must have and apply appropriate sanctions against members of its workforce who fail to comply with the privacy policies and procedures of the Covered Entity with regard to the new breach notification provisions 33 4 Implementation of Policies and Procedures Covered Entities are now required to implement policies and procedures with respect to the new breach notification rules 34 5 Required Changes to Policies or Procedures Covered Entities are required to change their policies and procedures as necessary and appropriate in light of the new breach notification rules 35 6 Process for Complaints The Covered Entity is required to provide a process for individuals to make complaints concerning the Covered Entity s policies and procedures with respect to the new breach notification provisions 36 7 Protection for Individuals Who Complain A Covered Entity cannot intimidate threaten coerce discriminate against or take any retaliatory action against any individual for the exerciseof any rights established under the new breach notification requirements 37 8 Prohibition of Waiver Covered Entities are prohibited from requiring individuals to waive their rights under the new breach notification provisions as a condition of the provision of treatment payment enrollment in a health plan or eligibility for health benefits 38 E Incidental Disclosures Under HIPAA a Covered Entity is permitted to use or disclose Protected Health Information incident to a use or disclosure otherwise permitted or required by the Privacy Rule 39 so long as the Covered Entity has complied with the requirements of the minimum necessary standard 40 and has implemented the requisite administrative technical and physical safeguards 41 Therefore if for example an improper match is returned to a requester using the Record Locator Service then such use or disclosure is arguably incident to a use or disclosure otherwise permitted or required by the Privacy Rule The preamble to the breach notification rule under the HITECH Act further clarifies the concept of an incidental use or disclosure being a permitted use or disclosure under the Privacy Rule In contrast a use or disclosure of protected health information that is incident to an otherwise permissible use or disclosure and occurs despite reasonable safeguards and proper minimum necessary procedures would not be a violation of the Privacy Rule pursuant to 45 CFR 164 502 a 1 iii the incidental disclosure provision and therefore would not qualify as a potential breach 42 Therefore if an improper match is returned from the Record Locator Service and such use or disclosure is deemed to be an incidental use or disclosure that qualifies under 45 CFR 164 502 a 1 iii then it would not be a breach under the new breach notification regulations If however a requestor obtains Protected Health Information about an individual in a way that does not qualify as an incidental use or disclosure under 45 CFR 164 502 a 1 iii then the Covered Entity must conduct a risk assessment as discussed in Section V C above to determine whether a breach has occurred Moreover based on the particular facts and circumstances the Covered Entity should also analyze whether one of the exceptions to unauthorized access of Protected Health Information applies as discussed in Section V B 2 Back to top VI Written Contract Extending Covered Entity s Obligations A Written Agreement Required The HITECH Act requires a Covered Entity to have a written contract with all organizations that provide data transmission of Protected Health Information to the Covered Entity and require access on a routine basis to Protected Health Information such as a Health Information Exchange Organization a Regional Health Information Exchange an E prescribing Gateway or a vendor that contracts with a Covered Entity to act on its behalf by offering a personal health record to patients as part of such Covered Entity s electronic health record 43 Each such entity must enter into a written contract to document assurances that Protected Health Information will be properly safeguarded as well as to apply the required administrative safeguards 44 Back to top VII Marketing Under the HITECH Act Protected Health Information generally cannot be used for marketing purposes unless certain specific exceptions apply A Any Communication that Promotes a Service or Product In general the HITECH Act clarifies that a communication paid or unpaid made by a Covered Entity or business associate that is about a product or service and that encourages recipients of that communication to purchase or use the product or service is not considered a healthcare operation but rather considered to be marketing unless such communication is made i to describe a health related product or service or payment for such product or service that is provided by or included in a plan of benefits of the Covered Entity making the communication ii for treatment of the individual or iii for case management for care coordination for the individual or to direct or recommend alternative treatments therapies healthcare providers or settings of care to the individual 45 B Exceptions to the Rule Even if one of the exceptions i iii listed above were to apply where the Covered Entity or business associate receives or has received direct or indirect payment in exchange for making a communication such communication is still considered marketing unless one of the following exceptions apply 1 the communication describes a drug or biologic that is currently being prescribed for the recipient of the communication and the payment is reasonable 2 the communication is made by the Covered Entity and the Covered Entity obtains a valid authorization from the recipient with respect to the communication or 3 the communication is made by a business associate on behalf of the Covered Entity and the communication is consistent with the written contract between such business associate to the Covered Entity 46 Back to top VIII Sale of Protected Health Information A Sale of Protected Health Information Prohibited Generally the sale of Protected Health Information is prohibited under the HITECH Act unless a Covered Entity obtains a valid authorization from the individual that includes a specification of whether Protected Health Information can be further exchanged for remuneration by the entity receiving the Protected Health Information 47 B Certain exceptions to this rule apply for public health activities research if the price charged reflects the cost of preparation and transmittal of the data for the treatment of the individual for a health care operation related to the sale transfer merger or consolidation of the Covered Entity for remuneration that is provided by a Covered Entity to a business associate for activities on behalf of such Covered Entity and that involves the exchange of Protected Health Information to provide an individual with a copy of such individual s Protected Health Information or as otherwise determined by the Secretary of the U S Department Health and Human Services 48 Back to top IX Limited Data Sets and the Minimum Necessary Standard Under the HITECH Act to comply with the HIPAA Privacy Rule s minimum necessary requirement Covered Entities must to the extent practicable limit the use disclosure or request of Protected Health Information to a limited data set If needed however the Covered Entity can rather than utilizing a limited data set limit the use disclosure or request of Protected Health Information to the minimum that they deem necessary to accomplish the intended purpose 49 Prior to the HITECH Act Covered Entities were required to use disclose and request the minimum necessary Protected Health Information to accomplish the intended purpose but there were no further defining criteria for compliance with this requirement Under the original HIPAA Privacy Rule use of limited data sets was not linked to compliance with the minimum necessary standard Rather limited data sets were previously used only for public health research or healthcare operations Now under the HITECH Act a Covered Entity must limit to the extent practicable the use disclosure or request of Protected Health Information to a limited data set Covered Entities may now have to make use of limited data sets more frequently when disclosing health records A limited data set consists of Protected Health Information from which an extensive list of personal identifiers is removed 50 Back to top X Fundraising Any written fundraising communication that is a health care operation must provide an opportunity for the recipient of such communication to elect not to receive any further fundraising communication 51 Back to top XI Patient s Right to Request Nondisclosure An individual has the right to request that a Covered Entity restrict the disclosure of the Protected Health Information of such individual 52 Pursuant to the HITECH Act a Covered Entity must honor such request if the disclosure is to a health plan for purposes of carrying out payment or health care operations and where the Protected Health Information pertains solely to a health care item or service for which the healthcare provider has been paid out of pocket in full 53 Prior to this change individuals were permitted to request a restriction on a Covered Entity s use and disclosure of Protected Health Information but the Covered Entity was permitted discretion regarding whether to comply with such restriction Back to top XII Patient Access to Protected Health Information A Must Provide Copy of Record Covered Entities maintaining electronic health records are required to give individuals copies of the records in electronic form HIPAA required Covered Entities to provide individuals with a copy of their Protected Health Information in the form or format requested if readily producible and if not readily producible in such form or format in readable hard copy form 54 The HITECH Act clarifies this obligation by requiring that a Covered Entity that utilizes or maintains an electronic health record must provide copies of Protected Health Information in electronic format to an individual or to such individual s designees who requests his or her information in such format 55 B Charging Costs A Covered Entity can typically charge a reasonable cost based fee that includes copy costs postage and the cost of preparing an explanation summary of the Protected Health Information provided in response to an individual s request However the HITECH Act limits the fee associated with the Covered Entity s provision of a copy of electronic health records The Covered Entity may impose a fee for providing electronic information or summary or explanation of such information to the requesting individual but such fee may not be greater than the entity s labor cost in responding to the request for the copy or summary or explanation 56 Back to top XIII Expanded Accounting of Disclosures of Protected Health Information Maintained in Electronic Format A Must Account for Disclosure for Treatment Payment and Health Care Operations For Covered Entities that use or maintain electronic health records the HITECH Act eliminates the Privacy Rule exception to exclude from their accounting to individuals disclosures of Protected Health Information related to treatment payment and health care operations Upon the effective dates set forth in the HITECH Act Covered Entities must provide an accounting of all disclosures of Protected Health Information including for treatment payment and health care operations TPO if the disclosure was made through an electronic health record during the previous three years 57 The effective date for Covered Entities that implemented an electronic health record system after January 1 2009 was January 1 2011 or the actual date the electronic health record system was implemented although the effective date may be extended at the Secretary s discretion to 2013 58 The HITECH Act requires the Secretary to promulgate regulations clarifying the types of information required to be collected about such disclosures 59 Until this guidance is issued and the Secretary indicates whether the effective date of this provision has been extended Covered Entities whose electronic health record systems were implemented after January 1 2009 should provide an accounting of disclosures of Protected Health Information for TPO purposes made through an electronic health record B Who Makes Accounting to Individual Covered Entities can now either directly account for disclosures made by business associates or provide a list of business associates to be contacted for an accounting thus shifting the burden to the business associate to report disclosures of Protected Health Information directly to the individual if such individual requests the accounting from the business associate 60 Back to top XIV Effective Dates A Except as otherwise stated below the HITECH Act provisions became effective twelve months after enactment on February 17 2010 61 B Depending on when a Covered Entity acquires an electronic health record the effective date of the new accounting regulations varies For electronic health records acquired as of January 1 2009 the new accounting rules apply to disclosures of Protected Health Information made from that electronic health record on and after January 1 2014 For electronic health records acquired after January 1 2009 the accounting rules apply to disclosures made on and after the later of January 1 2011 or the actual date the Covered Entity acquires an electronic health record The compliance dates may be postponed for up to two years if it is deemed necessary by the Secretary of the U S Department of Health and Human Services 62 C The restrictions on marketing communications went into effect and apply to written communications occurring on or after February 17 2010 63 D The new fundraising rule went into effect and applies to written communications occurring on or after February 17 2010 64 E The provision requiring the Secretary to formally investigate complaints of willful neglect went into effect as of February 17 2011 65 F The tiered increase in amount of civil monetary penalties applies to violations occurring after February 17 2009 66 G The provisions regarding enforcement by state attorneys general apply to violations occurring after February 17 2009 67 H The effective date of the Interim Final Rule Breach Notification for Unsecured Protected Health Information 45 C F R pts 160 and 164 was September 23 2009 which was 30 days after the publication of the interim rule as required by the HITECH Act 68 The enforcement date of the Interim Final Rule is February 22 2010 69 XV Regulatory Guidance On July

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-professionals/key-laws-and-regulations (2016-02-10)
    Open archived version from archive

  • Consent | Markle | Advancing America's Future
    sharing efforts applicable state law will set explicit consent policy that must be followed However for some states there are no additional legal requirements requiring individual consent to be obtained In either case health information sharing efforts will need to determine whether to adopt a policy on consent that goes beyond what the law may require Jenny Smith Louisiana Health Care Quality Forum past Addressing consent is more complex than we expected it to be We discovered many layers to state laws that surfaced technical and legal questions For example we learned that under Louisiana law consumers have the right to consent But we needed to understand what that means Does the law require consent to share the data or consent to use the data Can we aggregate data in a health information exchange without individual patient consent or do we need consent before this data is aggregated The process to address the complexity of this topic requires a very significant level of legal expertise financial resources and time Developing a consent policy based on FIPPs A three step process Consent policy development must account for other important technical and policy attributes of information sharing and is effective only when considered within the entirety of the circumstances of exchange that occur in any particular health information sharing effort Consequently setting effective policy on individual consent will be nearly impossible if the issue is taken up first before the basic boundaries objectives and model of information sharing have been established This Policies in Practice recommends a sequence for developing privacy and security policy Step 1 Initiate a policy setting process based on sound governance principles Step 2 Consider all of the FIPPs based privacy principles together to develop a set of specific baseline policies Step 3 Address the FIPPs based privacy principles of Individual Participation and Control and Openness and Transparency last when determining policies with respect to consent Consent is last in the sequence above because this set of policies what choices people will have and how they will exercise them should only be made once the circumstances of the health information sharing and the other key data sharing policies are considered Thus its placement in the sequence reflects its innate dependency on other foundational policy decisions This sequence also describes a process that can be deployed to re evaluate decisions on consent as circumstances change Consent policy development is not a one time process Such policies must be revisited or refreshed from time to time such as in response to changes in law or policy technology decisions for example an expansion of acceptable uses of the network or the addition of new technical functionalities or the scope or purpose of information sharing The expectations of individuals about the uses of their data may also change over time based on increased participation in health information sharing by providers Individuals may also change their data sharing preferences in response to changing life circumstances for example health status or marriage status Implementation at both the policy and technology levels needs to accommodate the ability for individuals to change their choices over time and have them prospectively honored Back to top IV Sequencing of Decisions Getting to the Details Step 1 Initiate a Policy Setting Process Based on Sound Governance Principles Coming to agreement on workable information sharing policies requires broad objective and inclusive involvement from various participants and the public at large in order to get appropriate and relevant feedback and to secure early buy in as well as ongoing support Public trust will occur through both sound policies and an inclusive process which also includes having consumers at the decision making table For more information on policies and practices for trust and interoperability with meaningful consumer participation see Governance of Health Information Sharing Efforts Achieving Trust and Interoperability with Meaningful Consumer Participation Step 2 Consider all of the FIPPs based privacy principles together to develop a set of specific baseline policies Purpose Specification and Minimization principle Determining the purposes for sharing heath information is the critical first step in determining the appropriate data sharing policies that will accomplish those purposes Many initiatives start by information sharing for individual treatment purposes only and limiting information sharing to those who are involved in the individual s treatment Some initiatives broaden the permissible uses to include other lawful purposes for data sharing such as for payment operations public health and other research In addition the types of entities permitted to participate in information sharing may broaden as the purposes for information sharing expand Still other initiatives permit sharing for any lawful purpose without additional policy limitations Regardless of whether the permitted purposes for information sharing are broad or more confined this information is part of the risk benefit calculus for information sharing and will be critical to determining whether and to what extent individuals will have choices with respect to whether their information is part of or shared through a health information sharing effort Collection and Use Limitation principles The minimization principle is reflected to some extent in the HIPAA minimum necessary standard and will likely vary depending on the purposes for which data is to be collected accessed or disclosed For example the information needed in order to treat an individual who seems to be suffering from flu symptoms will be different from the information needed to report a case of the flu to public health authorities In the Markle Common Framework Policy Guide P2 Model Privacy Policies and Procedures for Health Information Exchange SNO Policy 400 describes potential purposes for information sharing and policies for data minimization SNO Policy 600 specifically addresses the policy of minimum necessary Joe Heyman solo gynecologist Wellport Health Information Exchange Steering Committee member Massachusetts To start the consent policy conversation we began by identifying what data would be available through the health information exchange This took months Ultimately we decided that we would exchange the shared health summary or Continuity of Care Record CCR We had a lot of hearty discussion and conversation about whether additional information beyond that which is included in the CCR should be shared For example we debated whether we should include smoking status and alcohol use and certain sensitive categories of information These discussions took time But it was all with an eye toward how we were going to address consent In addition to addressing what data would be shared critical decisions were made about the specific purposes for which the data were being shared We decided to only permit users to view patient information when they were taking care of that patient We explained the permitted uses to the patient when we sought consent Our patient consent form details the purposes for use of the data and makes clear that the information won t go beyond the medical community i e those providers directly involved in the patient s care Once participants have determined the permissible purposes for sharing of health information policies and technology must be implemented to limit the collection and use of information to those purposes Implementing the principle of collection and use limitations also includes establishing internal policies regarding which individuals and entities have the right to access information consistent with the permissible purposes In P2 Model Privacy Policies and Procedures for Health Information Exchange SNO Policy 400 describes the use and disclosure policies SNO Policy 700 describes policies with respect to workforce agents and contractors Security Safeguards and Controls principle Once the policies are set regarding i permissible purposes for information sharing and ii collection and use limitations that are limited to those purposes the next step is to consider the security policies and protocols that will support compliance with those policies For example participants in a health information sharing initiative can deploy technical tools like role based access and audit logs to ensure access to information only by persons who are authorized to do so Encryption can help protect information from theft or loss Individuals will want to understand the reasonable security safeguards that will be in place to protect their information P5 Authentication of System Users P7 Auditing Access to and Use of a Health Information Exchange and P8 Breach of Confidential Health Information provide examples of security policy issues to be addressed Data Integrity and Quality principle The quality of health care depends on accurate health information Accurately matching individuals with their health information is critical to maintaining data quality Inaccurate health information can also adversely affect an individual s benefits and protections Does Consumer Control Lead to Incomplete Information Often providers are concerned that patients may choose to withhold important information and that without complete information the system will be less useful In reality however complete information about any patient is an aspiration at best No one can assume that any information derived from a fragmented delivery system used by patients over many years can ever provide an absolutely complete patient record whether on paper or electronically Clinicians know well that in the analog world information is often missing Sometimes patients withhold information from new providers until they establish a relationship This basic paradigm will be true in the digital world as well Using technology to override this or any policy expectation that individuals may have can quickly erode trust Giving individuals some informed control over how their information is shared is critical to building trust among patients and providers Within P2 Model Privacy Policies and Procedures for Health Information Exchange see SNO Policy 300 Individual Participation and Control of Information Posted to the RLS In addition implementers should consult T5 Background Issues on Data Quality and P4 Correctly Matching Patients with Their Records for further assistance Providing individuals with a way to review and request corrections to their health information also can improve data integrity and quality Policies regarding individual access to health data and requesting amendments to health data can be found at P6 Patients Access to their Own Health Information and P2 Model Privacy Policies and Procedures for Health Information Exchange SNO Policy 800 Amendment of Data Accountability and Oversight and Remedies principles Privacy and security policies have little effect if violators are not held accountable for compliance failures Employee training privacy and security audits and other oversight tools can help to identify and address violations and breaches by holding accountable those who violate privacy requirements and by identifying and correcting weaknesses in security systems In addition remedies must exist to help hold violators accountable and to make recompense to persons who are aggrieved by privacy violations Relevant model policies in P2 Model Privacy Policies and Procedures for Health Information Exchange include SNO Policies 100 Compliance with Law and Policy 700 Workforce Agents and Contractors and 1000 Mitigation also relevant are P7 Auditing Access to and Use of a Health Information Exchange and P8 Breach of Confidential Health Information Step 3 Address the FIPPs based privacy principles of Individual Participation and Control and Openness and Transparency last when determining policies with respect to consent Individual Participation and Control principle Once implementers have established policies defining the context for sharing information including how individuals and entities will be held accountable for complying with such policies implementers can meaningfully consider whether and how individuals should be provided with choices regarding information sharing Relevant model policies in P2 Model Privacy Policies and Procedures for Health Information Exchange include SNO Policy 300 Individual Participation and Control of Information Posted to the RLS P3 Notification and Consent When Using a Record Locator Service also provide details on consent policy when using a Record Locator Service model for health information exchange This principle also addresses individual access to health information and the right to request an amendment Consent for Patient mediated Exchange This Policies in Practice focuses on whether and how to implement consent with respect to the sharing of electronic health information typically among health care professionals health care institutions like hospitals and health plans However the implementation of the Health Information Technology for Economic and Clinical Health HITECH is likely to facilitate even greater sharing of health information directly with and by patients HITECH amended the HIPAA Privacy Rule to make it clear that patients have the right to receive an electronic copy of their health information when their health information is maintained in electronic form Refer to Key Laws and Regulations Changes Relevant to the Markle Common Framework In addition the Meaningful Use program requires some affirmative sharing of health information with patients and these requirements may increase in later stages of that incentive program At present the Department of Veterans Affairs Centers for Medicare and Medicaid Services Department of Defense and an increasing number of private sector entities are offering individuals the opportunity to view and download electronic copies of their health information This capability can facilitate patient initiated health information sharing Markle Connecting for Health has developed a set of consensus policies specifically for the download capability that build on the Markle Common Framework for Networked Personal Health Information See also Individual Access Connecting Patients with Their Health Information What Granularity of Choice to Offer Implementers deciding to provide individuals with choices regarding information sharing will need to consider how granular those choices should be For example choice can be all in or all out or at the more granular level choice of health information sharing participation may be by individual provider or type of provider or by type of data State and federal law varies with regard to requirements related to granularity For example some states require granularity on the level of individual choice because they require specific consent for certain types of information Similarly federal law requires explicit consent for substance abuse treatment data in some circumstances and requirements enacted by Congress in 2009 provide individuals with the right to restrict disclosures to health plans See Key Laws and Regulations Changes Relevant to the Markle Common Framework Other policy recommending bodies have called for more granular choice For example in Recommendations Regarding Sensitive Health Information the National Committee on Vital and Health Statistics recommended that electronic health records have the capability to sequester or segregate data in specific sensitive categories Relevant model policies in P2 Model Privacy Policies and Procedures for Health Information Exchange include SNO Policy 500 Information Subject to Special Protection and SNO Policy 900 Requests for Restrictions Yet there is a limit to how granular consent can be implemented in today s complex environment Health information streams are complex and involve an ever growing number of users Even medical professionals are unlikely to understand the full scope of information sharing that occurs in day to day health care delivery For example CT1 Technology Overview Appendix A Data Flow Scenarios follows the data trail of a single drug prescription the most common clinical transaction Just to put the pills in the bottle under the simple scenario there are 10 different electronic copies of the information stored in various databases 4 In addition greater innovation and development of technology is needed to allow for consent at the more granular levels ONC s Health IT Policy Committee conducted a hearing on consent technologies and concluded that promising models were in development but not necessarily in widespread use We may be years away from widely deployed reliable solutions In the meantime policies on choice need to reflect both what is desirable and what can be accomplished HHS is piloting more granular consent technologies Making Individual Choice Meaningful and Understandable But is it Opt in or Opt out Many discussions about consent policy options become focused on the sole question of whether health information sharing entities should require opt in or opt out by individuals Unfortunately this paradigm is a gross oversimplification of the complex data sharing decisions that provide the foundation for policies on individual consent It doesn t reflect how the context of data sharing can influence appropriate and effective consent policy Merely saying opt in or opt out says nothing about the context of data sharing For example providing individuals with choices based on whether or how much of their information can be accessed or queried for what purposes with what protections whether and how its made available for sharing with other providers and whether a database that contains copies or summaries of provider records is used is essential to consider and a much more complex decision than a binary choice In addition opt in or opt out also says nothing about whether meaningful choice is provided or presented in a way that individuals understand The choice provided should be meaningful and understandable to individuals including informing them about the data sharing practices and discussing the benefits and risks of participating or not participating The federal Health IT Policy Committee recommended that individuals be provided with meaningful choice when their information is made accessible through certain types of exchange structures The elements of meaningful choice include Allows the individual advance knowledge time to make a decision e g outside of the urgent need for care Is not compelled or is not used for discriminatory purposes e g consent to participate in a centralized HIO model or a federated HIO model is not a condition of receiving necessary medical services Provides full transparency and education i e the individual gets a clear explanation of the choice and its consequences in consumer friendly language that is conspicuous at the decision making moment Is commensurate with the circumstances i e the more sensitive personally exposing or unexpected the activity the more specific the consent mechanism Activities that depart significantly from patient reasonable expectations require greater degree of education time to make decision opportunity to discuss with provider etc Must be consistent with reasonable patient expectations for privacy health and safety Must be revocable i e patients should have the ability to change their consent preferences at any time It should be clearly explained whether such changes can apply retroactively to data copies already exchanged or whether they apply only going

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-professionals/consent (2016-02-10)
    Open archived version from archive

  • HIE Governance | Markle | Advancing America's Future
    if it is executed and enforced and involves broad adoption of practices policies and technologies Implementation often happens through a combination of top down and bottom up approaches A top down approach involves traditional oversight and execution by a dedicated staff A bottom up method focuses on the critical role played by participants such as health care providers and consumers who must abide by adopted policies Evaluation and review Steps must be taken to ensure that there are resources and agreed upon indicators to evaluate the impact and the cost benefit balance of an information policy or particular technical approach One important consideration in any evaluation is whether a separate structure or body may be required to conduct such evaluations and reviews for example in the oversight and audit of third parties Example Governance Stages from the Health Information Partnership for Tennessee Health Information Partnership for Tennessee HIP TN is a Tennessee not for profit organization that works to improve access to health information through a statewide collaborative process by providing services and infrastructure for the secure electronic exchange and use of health information This vignette describes the governance stages from problem identification to evaluation and review that will lead to the development of a service for providing access to patients complete medication histories Governance Stage Activity Problem identification and agenda setting For several years the participants and staff at the Health Information Partnership for Tennessee HIP TN heard anecdotal accounts that providers were frustrated with their inability to access a complete and up to date medication history list for patients The HIP TN Clinical Workgroup found that improving access to a complete medication history was a priority for network participants and would provide value to the community A complete medication history is very important for understanding a patient s health status and for preventing medication errors but providers had a difficult time compiling a complete list because prescription information is spread out across multiple entities and patients have a hard time remembering what is often a laundry list of medication names and doses The HIP TN Board assembled a small group to outline an approach for developing a medication history service Design formulation and adoption An Advisory Group was established to gather input from HIP TN participants representing different a broad range perspectives in order to understand the issues and develop possible solutions The Advisory Group itself was also composed of a broad range of network participants including providers and clinicians large provider practices primary care practices specialty practices hospitals academic medical centers rural practices Nurse Practitioners nurses health plans disease management organizations and pharmacists retail pharmacies clinical pharmacies The Advisory Group conducted focus groups surveys and interviews with community members throughout the state to inform a set of recommendations for a medication history service They shared these recommendations with the HIP TN CEO who in turn delivered them to the HIP TN Board Once the Board approves the recommendations they will be shared publicly on the HIP TN website Implementation and enforcement This project has not reached the implementation phase However the Advisory group offered several recommendations to guide the implementation process including Adopt a phased approach to the development of a medication history service that builds trust with users and expands existing capabilities over time It must be user friendly and give users a high confidence in the data presented to them A timeline should be established to guide these phases Use data from pharmacies as the backbone for a medication history service This will require contracts with pharmacies and technology vendors among others Explore many possible funding options to help develop the medication history service Over time explore methods to split costs across the groups that ultimately benefit from the service Adopt a high degree of entrepreneurship to guide the implementation efforts and to make this a viable service for healthcare providers in Tennessee There is a strong need for a systematic approach that better ensures the acquisition of accurate and complete medication histories Involve the community throughout the implementation process and incorporate feedback on an ongoing basis Provide project management through HIP TN s Program Management Office Evaluation and review The Medication History project is one of many projects managed by HIP TN The HIP TN Board will review the project status every month during a regularly scheduled meeting The Board consists of licensed healthcare providers hospitals local health information sharing efforts health insurers self insured employers a consumer director and representation from the Tennessee Regional Extension Center The Board will evaluate the project against the set of recommendations developed by the Advisory Committee and feedback from the community HIP TN s Program Management Office will also provide intensive project management evaluate progress on a regular basis and address issues and risks as they emerge This office reports to the CEO and the Board and engages HIP TN s workgroups as appropriate The office also works closely with the staff from the state government and the technology vendors for HIP TN and will engage these entities where appropriate Back to top III Principles and Characteristics of Good Governance A number of principles and characteristics can be applied when establishing or evaluating governance for health information sharing efforts Appropriate and successful governance efforts demonstrate the following Participation Transparency Representation Effectiveness Well defined and Bounded Mission Accountability Each characteristic is described below Participation Regular and intentional public outreach and deliberations are an important aspect of legitimate decision making and governance processes Policies and procedures developed through a collaborative process that seeks early input promotes broad participation and provides public comment periods have a greater likelihood of being understood and supported by those they are designed to serve Carol Robinson Oregon Office of Health Information Technology In Oregon public participation played a big role in our governance efforts We identified the need to include the public as we developed our strategic plan and more specifically we sought specific input on our approach to consent The facilitation of public meetings was a key mechanism to ensure public participation Our first public meeting where we addressed information sharing policies had about 160 people in attendance To seek additional public input we conducted a post meeting survey which focused on the consent policy and even held town hall meetings across the state to ensure that we had maximum input Transparency and Openness It is also important to provide clear explanations for the rationale behind final policies and decisions This includes documenting the processes and decisions of any workgroups or subgroups and addressing comments received by the public Transparency should be a goal in other administrative respects including how operations are financially supported and sustained New Participatory Tools For Health IT Governance While health information technology IT is transforming the health care delivery system new participatory tools are also transforming how health IT governance is conducted especially as it relates to engaging the public in important policy making processes Although this Policies in Practice does not aim to elaborate on all of the tools being used including social networking Wikis and other collaborative platforms notable advances should be considered where they can transform and improve governance practices including providing opportunities for greater transparency and broader participation IT tools can exponentially improve how the public is informed and participates in decisions and help to ensure that governance interventions are responsive to the needs and preferences of those that they are intended to benefit IT may also provide innovative ways for the public to monitor and evaluate health information sharing efforts progress in meeting goals and may support mechanisms for dispute resolution Often IT tools can provide a more supportive transparent and timely application of governance principles Some cross sectoral examples of IT enabling greater consumer participation in the governance process include The World Wide Web Consortium W3C uses an online forum to develop open web standards The consortium is an international community where member organizations and the public work together to develop Web standards like HTML Their online forum enables people to connect across the globe and participate in real time discussions about ideas on new and existing work Tools like the W3C Forum enable participation across traditional geographic boundaries and enable all Web users the opportunity to engage 311 is used by many city and state governments as a gateway for citizens to access government information and services 311 was initially set up as a simple three digit phone number similar to 911 for emergencies but has expanded to the web in recent years Several city and state governments are going one step further and are now using social media as a tool for solving issues that emerge in real time by opening up their 311 platforms to private technology developers By opening their 311 platforms citizens can now use tools from their everyday lives like texting or tweeting to report problems ranging from potholes to broken street lights Unlike 311 in the past developers can integrate information from varied publicly available reports and assemble them in mash ups that track the status of repairs or improvements in real time and show trends over time on the web creating both transparency and accountability Peer to Patent opens the United States patent examination process by connecting volunteer scientists and technologists with federal patent examiners Patent examiners have historically evaluated long complex and technical claims cut off from any external information This new program establishes a legitimate mechanism for channeling the expertise of these volunteers into information patent examiners can use when making their final determination about patents against established legal standards Representation Meaningful engagement and balanced representation of a wide variety of participants including patients and consumers is critical to the success of health information sharing efforts Because the goal of safe secure and appropriate health information sharing depends on the buy in and participation of a wide variety of health care system participants that same range of engagement and input is required for governance to succeed Public private partnerships are often considered effective governance models because these partnerships can enable broad participation both within and outside of government All participants should come to the governance process with the aim of solving mutual challenges standing in the way of shared goals 9 Making broad and balanced participation a priority ensures that health information sharing initiatives are not unduly influenced by the size resources or specialized knowledge of any one interest group It also ensures that the needs of those the health information sharing effort aims to serve are fully known and expressed Although participation make up will vary the input of all members should be equally valued As such it is crucial to ensure that patients and consumers in particular not only have a seat at the table and a voice but are in a position to substantially influence decisions Their decision making influence in developing and meeting quality and sustainability goals will contribute significantly to broader acceptance and trust and therefore ultimately success Phyllis Albritton Colorado Regional Health Information Organization past Our board is composed of decision makers and visionaries As CEOs they have the broad view of what is best for their organizations and their customers and patients They think creatively about policy decisions from both a strategic as well as an operational standpoint There is a recognized responsibility to both CORHIO and the organizations they represent providing a structure for shared accountability as policies are implemented We don t have a consumer specific panel for the following reason When we started down that road the consumer representatives asked why they were segregated from all of the activity on other committees That wasn t our intent Our intent was to make sure that we were very intentional about consumer issues So they suggested that we try a new approach making sure that there are consumer representatives on all of the committees So that s the way we structure ourselves now Effectiveness A successful governance model will create the structure and processes needed to support effective and efficient decision making To operate effectively governance efforts need adequate resources and staff who are knowledgeable dedicated and able to execute the policies and procedures No single governance model works for all information sharing efforts but rather an array of tools and processes that can be used by different entities and or participants Flexibility Policies and procedures need to be flexible Governance models should keep members informed and enable them to react quickly to a changing environment This could include new opportunities or potential barriers as they relate to public trust and operational sustainability funding access to expertise and different jurisdictional requirements Governance models should also accommodate constant and rapid innovations in technology Flexibility will allow an entity to incorporate and maximize use of these technological innovations and thus governance policies should remain technology neutral While precise policies should be developed with respect to desired functionality and outcomes the means of achievement should not be overly prescriptive This could lock in a specific type of technology or tool that may later prove sub optimal Well defined and bounded mission A plainly articulated vision that clearly sets forth the value case for information sharing as well as a well defined scope of authority will help ensure that the governance processes are timely relevant and appropriate The scope should be limited to the necessary policies and procedures that must be commonly defined and agreed upon to achieve these two high level objectives Clearly articulating a high level mission is critical for prioritizing strategic objectives and addressing issues appropriately as they emerge over time In the context of the Markle Connecting for Health Common Framework for Private and Secure Health Information Exchange adopting two high level goals helped to circumscribe the scope of efforts these two goals include the following 1 improving health while establishing trust and 2 assuring interoperability while encouraging innovation Accountability Accountability is a vital element of any governance process and should include procedures for the submission and handling of complaints related to policy violations In addition a clear and public dispute resolution process should be developed Annual reports independent audits and external reviews are other good methods of ensuring accountability and identifying areas for appropriate enforcement Health information sharing efforts have a range of accountability and enforcement mechanisms to choose from to best fit their particular objectives and circumstances but the existence of each should be shared publicly The implementation of an oversight committee is one way to ensure that mechanisms are put in place and maintained effectively Additional information on accountability and oversight can be found in the Policies in Practice Mechanisms for Oversight Accountability and Enforcement The Model Contract Update and More Feature In depth look at how governance efforts effectively engage consumers Meaningful consumer participation in both the establishment of policies and their implementation and enforcement is a necessity Having the perspectives of patients and families is vitally important to sound governance practices Many consumers and consumer advocates are well informed about health care issues and can both articulate and develop patient centered policies and practices Why is involving consumers beneficial 10 Consumers and their advocates have the unique ability to represent and give voice to the needs and wants of patients and families because Consumers and their advocates are in regular contact with their constituents understand their experiences and views and can offer a perspective that is informed by a diversity of patient experiences from the underserved to seniors to patients with specific diseases as well as their own personal encounters with the health care system Consumers and their advocates can be highly effective and trusted distributors of information to consumers They typically have a variety of ways in which they communicate with their constituencies including websites newsletters broadcast e mails conferences and mailing lists Additionally consumer advocates can connect governance bodies with their constituencies to solicit input on governance projects policies and procedures Consumers and their advocates may have earned the respect of community members and established relationships with health information sharing participants as well as policy makers and elected and appointed community leaders These relationships can be used to communicate quickly and effectively with the community and can help mobilize a broad base of consumers to take actions when appropriate for example when commenting on or approving proposed governance policies Consumers and their advocates may be well integrated into the communities they serve and can therefore help ensure that the governance processes are resulting in decisions and practices that benefit the community Consumers and their advocates can function as translators by promoting the work of health information sharing efforts in ways that resonate with and are meaningful to the public Definition of a consumer advocate or consumer representative 11 Most often a consumer advocate is an individual who works at a nonprofit mission oriented organization that represents consumer interests The distinguishing features of such an organization include an emphasis on the needs and interests of consumers and the public interest without conflicts of interest The definition of consumers and their advocates or representatives needs to be flexible to allow communities to pick the most appropriate participants For example local educators faith leaders or social workers can represent the public interest or patient or family advocates can be excellent consumer representatives Individual consumers and patients also can be effective consumer advocates Those selected to represent consumers must be able to do so without competition or hidden agendas Approaches to meaningful multi participant engagement including consumers and their advocates Clearly define roles and responsibilities With the active involvement of all participants a governance process should consider and define the best roles for specific members Thinking through roles and responsibilities on the front end makes it more likely that they will be successfully fulfilled Once these roles have been decided expectations should be clearly articulated in order to protect against ambiguity or misunderstanding Be inclusive Participant roles should be decided upon collaboratively with all participants which will aid in integrating consumer

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-professionals/hie-governance (2016-02-10)
    Open archived version from archive

  • Getting Procurement Right | Markle | Advancing America's Future
    are applicable to a wide variety of health information sharing efforts Users of this Policies in Practice should also consult appropriate resources that address applicable federal state or other procurement requirements as well as state and other applicable privacy laws and regulations plus other guidance that they determine to be appropriate Health information sharing efforts should expect that their Privacy Policies will need to evolve over time Privacy Policies and health information sharing efforts policy development processes will be required to address changes and other developments in the laws that regulate health information privacy and sharing and in the overarching legal environment in which health information sharing occurs In addition evolving experience and expectations among health information sharing efforts health information sharing participants and the individuals and communities they serve will also require that health information sharing efforts Privacy Policies continue to evolve Therefore a policy aware arrangement with a health information technology health IT developer must include mechanisms to identify and accommodate the policy and technological changes that will be required over time This Policies in Practice provides a Description of key policy decisions Sample framework for making those decisions Recommended approach for having the health information sharing effort s policies reflected in its description to prospective vendors of its technical requirements for the Technology and Recommended approach by which the health information sharing effort can assure that prospective developers or vendors proposals respond to the health information sharing effort s policy driven specifications and other requirements These elements are supplemented by a recommended Glossary of important terms used in health IT procurement to assist procuring organizations and prospective vendors on how to communicate effectively regarding the organizations needs for Technology and how the prospective vendors products and services will satisfy those needs This Glossary incorporates a number of defined terms included in the Markle Common Framework for Private and Secure Health Information Exchange s Model Contract for Health Information Exchange such as referring to the health information sharing effort as a sub network organization or SNO Back to top II Assuring Support for and Compliance with Privacy Policies This Policies in Practice seeks to assist a health information sharing effort obtain technological support for and compliance with its Privacy Policies through Technology implementations that are most often conducted by health IT developers and vendors simultaneously providing a framework for reasonably protecting Patient Data from inappropriate uses and or disclosures and permitting the use of that Patient Data in ways that are both productive and meaningful In developing its Privacy Policies specifications for Technology and other materials for the procurement process as well as in reviewing prospective responses the health information sharing effort may wish to involve individuals with specialized expertise in IT and or privacy and security matters Involving subject matter experts early and throughout the policy development and procurement process can be helpful However to avoid actual or apparent conflicts of interest the health information sharing effort should consider managing the participation in a manner which may involve excluding prospective technology developers or vendors from some part or all of the process or otherwise In order to give prospective technology developers or vendors the opportunity to provide the relevant support the health information sharing effort must describe its privacy and security requirements in detail Early in the procurement process the health information sharing effort should provide copies of its Privacy Policies as well as the use cases and other materials described below or make other access to those materials available The health information sharing effort should also consider whether it wishes to provide specific objectives and measures to address some or all of the capabilities that they have determined need to be provided in the Technology In most circumstances the most effective means of describing the health information sharing effort s requirements would be to provide each prospective technology developer or vendor with a copy of the Privacy Policies together with any other appropriate documentation that explains the Privacy Policies or otherwise provides necessary context or describes any technical specifications The health information sharing effort may wish to consider supplementing its Privacy Policies by developing use cases that will allow prospective technology developers or vendors to present demonstrations of their Technology in specific situations and involving specific parties that demonstrate how they will comply with and accomplish the objectives of the health information sharing effort s Privacy Policies Such use cases should illustrate both the experience of the typical Authorized User of the Technology and the experience of Authorized Users with oversight responsibilities It is best to develop the written criteria by which it will evaluate prospective responses and or demonstrations Doing so can promote an atmosphere of openness and transparency to the procurement process and create a sense of shared goals that will facilitate effective relationships The following pages raise a number of issues regarding how the prospective Technology will assure that the health information sharing effort s System is compliant with the principles upon which its Privacy Policies are based The health information sharing effort should explain that each of these issues will require a response from the Technology that will implement the Privacy Policies The health information sharing effort should require that each response describe in addition the nature and extent of the Technology s flexibility and compatibility in exchanging information with other systems such as those with which the Technology will be used and any alternative technology to which the health information sharing effort will wish to affect a transition at a later time Prospective technology developers and vendors should be required to explain in their own words their understanding of the health information sharing effort s Privacy Policies in order to demonstrate an appropriate level of understanding and to help identify any issues for which clarification is appropriate In addition each should be required to explain and demonstrate how its Technology and processes work to support each factor measure and or standard that the health information sharing effort has required Prospective technology developers or vendors may be asked to provide alternative means to achieve the health information sharing effort s objectives with respect to each of these matters When a prospective Technology is not available for review and evaluation during the procurement process a number of additional issues are raised The health information sharing effort should obtain detailed commitments regarding compliance with specifications and delivery times together with remedial measures and fee adjustments In addition the health information sharing effort should review and analyze each prospective technology developer s or vendor s own privacy and security policies to determine whether those policies are consistent with the health information sharing effort s Privacy Policies or require changes to satisfy the health information sharing effort s requirements Note Capitalized terms have the meanings given to them in the attached Glossary which includes a number of terms defined in the Model Contract for Health Information Exchange Back to top III Key Privacy and Security Policies and Procedures to Guide Procurement ISSUE COMMENTS 1 What controls measures and or standards does the health information sharing effort require to assure that it achieves an appropriate degree of openness and transparency regarding developments procedures policies technology and practices with respect to the treatment of Patient Data Factors to consider include the ability of individuals to obtain an understanding of The information about them that is being collected made available for disclosure and actually disclosed and used i e Patient Data and How they can exercise reasonable control over their Patient Data The health information sharing effort will want to understand the extent to which the products and or services facilitate a making specified information available to Participants and Individuals b communicating that information to Participants and Individuals and or c providing a mechanism by which Participants and Individuals can communicate with the health information sharing effort regarding matters of concern The health information sharing effort should provide copies of or other access to their applicable policies and procedures to provide an understanding of the health information sharing effort s objectives regarding the promotion and maintenance of openness and transparency and any specific means adopted by the health information sharing effort to promote and or maintain openness and transparency including without limitation the health information sharing effort s notice of privacy practices It may be helpful for the health information sharing effort to provide a summary of its policy objectives regarding openness and transparency in order to describe clearly the specific objectives they are seeking to achieve with respect to these matters The health information sharing effort s specifications for the Technology should include any specific measures for openness and transparency described by their applicable policies and procedures or otherwise what they determined Specific matters to be addressed should include without limitation audit capabilities and how the Technology will support transparency and accountability e g the generation of alerts when certain potentially problematic events occur 2 What controls measures and or standards does the health information sharing effort wish to adopt to provide for purpose specification and minimization for Patient Data Factors to consider include Limitations upon the use of Patient Data to the minimum amount necessary to accomplish the health information sharing effort s specified purposes and Measures to prevent collection of Patient Data for unauthorized purposes and its use or reuse for different or unauthorized purposes Measures to track adherence to standards regarding minimum necessary uses and disclosures of Patient Data and The extent to which the Technology meet current and emerging interoperability standards The health information sharing effort will want to understand how the Technology products and or services assist in the management of purpose specification and minimization both with respect to the collection of that information and in connection with the making of that information for disclosure and or use through health information sharing efforts Again the health information sharing effort should provide copies of and or other access to all applicable policies and procedures It may be helpful to provide a summary of policy objectives and specific measures that are sought The prospective technology developers or vendor s privacy and security policies should be examined as well Specific matters to be addressed should include Response to queries Which information is returned in the query process Role based access How does an Authorized User s role effect what information is available based on the role Which information is exposed through the User Interface Which information is documented by each audit report for a patient query and retrieval of patient information 3 What measures and or standards does the health information sharing effort wish to adopt to accomplish collection limitation for Patient Data Factors to consider include Participants obtaining Patient Data by fair and lawful means only Participants obtaining Patient Data with the knowledge and or consent of the Patient if and to the extent required Measures to inform Patients of the methods and extent of information collection and the potential uses and abuses of their Patient Data in an electronic networked environment and Measures to track adherence to standards regarding minimum necessary uses and disclosures of Patient Data For each of these issues the prospective Vendor should explain and demonstrate how its privacy and security policies as implemented through the Technology accomplish these objectives In addition the prospective Vendor should provide a copy of its privacy policies and procedures Specific matters to be addressed should include Technology specifications to ensure that an Individual s documented desire for limiting Patient Data are communicated and that they are honored Requirements for role based access 4 What measures and or standards does the health information sharing effort wish to adopt to accomplish use limitation for Patient Data Factors to consider include Controls to reasonably assure use of Patient Data by Data Recipients for the purposes upon which they based their requests for that Patient Data Ability to permit other uses under appropriate exceptions e g law enforcement security etc Measures to provide for the exchangeof Patient Data only in compliance with each Data Provider s applicable policies and procedures and Measures to assure de identification and or anonymization of Patient Data for any other uses The health information sharing effort should develop specific measures based upon its privacy policies and require the proposal to describe how its products and services achieve each of these goals 5 What measures and or standards does the health information sharing effort wish to adopt to provide for Patients individual participation and control over their Patient Data Factors to consider include Extent if any to which the health information sharing effort wishes to adopt policies that impose requirements in addition to those that apply under HIPAA HITECH and other applicable laws Requirements regarding Patients consent or authorization for or imposition of restrictions upon their inclusion in the Record Locator Service RLS and or the exchange of their Patient Data or certain categories of Patient Data Measures to facilitate Patients requests for and receipt of information regarding who has their Patient Data and which Patient Data they have Measures to facilitate Patients requests for access to and copies of their Patient Data Measures to permit Participants to withhold such access and or copying when appropriate Measures to facilitate Patients requests for accountings of disclosures and amendments to Patient Data and Measures to facilitate communications to Patients regarding a Participant s decision to deny access to their information or to decline to make an amendment requested by the Patient The health information sharing effort should require a demonstration of how the Technology will support implementation of patient consent decisions as applicable e g prior notice opportunity to decline giving of specific authorization s etc In addition the Technology should support the application of each Data Provider s applicable policies for the exchange of Patient Data Finally the Technology should support the application of a Patient s differing consents on a Participant by Participant basis or with respect to the particular types of information involved 6 What measures and or standards does the health information sharing effort wish to adopt to assure data integrity and quality Factors to consider include Measures to assure that Patient Data is accurate complete relevant up to date and otherwise useful Measures to permit Patients to view their Patient Data and have it amended to assure accuracy and completeness and Measures to assure that queries to the RLS return results that are not over or under inclusive The health information sharing effort should require explanation and demonstration of how the Technology works to support each factor measure and or standard 7 What security safeguards and controls does the health information sharing effort wish to adopt to prevent loss corruption unauthorized use modification and or disclosure of Patient Data Factors to consider include Susceptibility of networked environments to cyber crime Design and implementation of technical and process based measures for accomplishing identification authentication and authorization for access to Patient Data Design and implementation of technical and process based security controls e g identity management tools data scrubbing hashing authenticating etc Availability of other tools to strengthen privacy and security Capabilities to apply different rules to different types of Patient Data e g sensitive data or other data specifically protected by law Capabilities to escape matching thresholds authentication or authorization requirements or other measures if appropriate and Capabilities to audit alert and report based on the health information sharing effort s policies The health information sharing effort should require explanation and demonstration of how the Technology works to support each factor measure and or standard 8 How does the health information sharing effort wish to accomplish and maintain accountability and oversight for compliance with privacy and security standards Factors to consider include Training of Authorized Users and others Oversight of Participants and Authorized Users Measures to track specified incidents e g incidental disclosures Measures to facilitate accountability e g availability to Data Providers and Data Users of information regarding uses and disclosures of Patient Data and compliance with privacy and security standards measures to support logging and audits Measures to enforce accountability for non compliance and Measures to help improve compliance e g identifying and correcting weaknesses The health information sharing effort should require explanation and demonstration of how the Technology works to support each factor measure and or standard In addition the prospective technology developer or vendor should be required also to demonstrate how its own internal controls for ensuring accountability and oversight support the accomplishment of their objectives 9 What measures does the health information sharing effort wish to adopt to provide remedies for privacy and or security breaches or other performance problems Factors to consider include Legal and financial devices Standards for accountability Standards for process and fairness Processes to communicate with Patients and Participants regarding compliance and corrective measures and Processes to mitigate harm caused by privacy and security violations The health information sharing effort should require explanation and demonstration of how the Technology works to support each factor measure and or standard To have a meaningful basis from which to determine when remedies are required and which remedies are appropriate to the circumstances prospective technology developers or vendors should provide specific service level and other commitments that will be incorporated into the Agreement and against which performance can be measured Back to top Glossary of Terms for Privacy and Security Terms for Procurement TERM DEFINITION COMMENTS Acceptable Use Policy Noun A set of rules and guidelines adopted by the health information sharing effort that specify appropriate uses of computer systems networks and or information Access Control Noun A mechanism or set of mechanisms designed to prevent the unauthorized access or use of Resources by limiting the number of parties that have access to or ability to use those Resources and or by limiting the scope of such access or ability to use those Resources Accountability Noun A mechanism or set of mechanisms that allows for the actions of an individual or other person with respect to the access

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-professionals/getting-procurement-right (2016-02-10)
    Open archived version from archive

  • CP2 | Markle | Advancing America's Future
    including the usability of the interface and the principle that consent should be proportionate i e the more sensitive or personally exposing the changes to policy then the more specific and discrete the mechanism to capture a consumer s consent and vice versa See CP3 Consumer Consent to Collections Uses and Disclosures of Information When a Consumer Access Service seeks a new authorization it should clearly explain the consequences of opting in and opting out of the new policies For example opting out may require the consumer to terminate use of the Consumer Access Service In such cases the Consumer Access Service should provide the consumer with an easy process for both downloading and printing the user s records See CP8 Consumer Obtainment and Control of Information and CT5 Portability of Information Appendix A Limitations of Relying on Notice and Consent The Federal Trade Commission s Fair Information Practice Principles declare The most fundamental principle is notice Consumers should be given notice of an entity s information practices before any personal information is collected from them Without notice a consumer cannot make an informed decision as to whether and to what extent to disclose personal information 4 However current industry practices of posting policy notices provide only limited protection for even the most careful consumer We conducted an in depth analysis of the privacy and terms of use statements of eight different PHR products chosen based on their relatively high levels of sophistication in data integration The organizations studied included three large integrated delivery networks a nationwide insurance company a nationwide retail pharmacy company and three independent companies offering PHRs with advertised capabilities to import professionally sourced health data for the consumer The examination based on publicly posted policies between June and August 2007 found challenges that will be familiar to any consumer who has signed up for software or services involving personal information over the web Organizations present significantly varying degrees of purpose specification collection and use limitations and offer varying granularity of individual participation and control options Those differences are very difficult to compare from one site to another because the posted policies are not standardized or organized in common formats Policies are typically lengthy and complex with fine print that may be vague highly technical or both Policies contain multiple notices about how personal data will be handled For example in at least one case protections listed in an organization s privacy policy could be changed under its terms and conditions of use both of which must be agreed to by the consumer Ideally terms and conditions would be a helpful guide to consumers spelling out the responsibilities and protections to be undertaken by each party However the terms and conditions we examined were typically written from the standpoint of limiting the company s liability and obtaining broad authorization from the consumer In fine print for example we found clauses that allowed disclosure of personal health information to an employer at the request of a consumer s health plan and or a denial of accountability or redress in the event of a misuse of personal data by contracted third party entities i e a lack of chain of trust reassurances Other studies have had similar findings For example one study that looked at 60 financial privacy notices and found that most were written at a 3rd 4th year college reading level instead of the junior high school level that is recommended for materials written for the general public suggesting consumers will have a hard time understanding the notices because the writing style uses too many complicated sentences and too many uncommon words 5 A 2002 study found that none of 80 health web sites examined had a privacy policy that would be comprehensible to most English speaking adults in the United States 6 A recent study commissioned by the American Health Information Community examined 30 PHR privacy policies and found them to be inconsistent and incomplete noting a general lack of specificity on uses and disclosures of information 7 The net result of such practices is an undue burden on consumers to determine what the policies say and do not say It is not surprising that most consumers do not read online privacy or terms of use statements 8 It s not uncommon for consumers to later be surprised by unwelcome consequences 9 This is deeply challenging in an infant industry that requires consumer trust to survive It is also important to note that notice alone does not protect consumers As evidenced by recent FTC and State Attorney General cases a company may still be engaging in unfair practices even when providing notice to the consumer if that practice could cause significant injury and is buried deeply in a disclosure 10 Appendix B A Survey of Recommended Areas for Policy Notice to Consumer The Federal Trade Commission s Fair Information Practice Principles are an essential starting point for online policy notice statements for consumers The FTC s notice principle reads While the scope and content of notice will depend on the entity s substantive information practices notice of some or all of the following have been recognized as essential to ensuring that consumers are properly informed before divulging personal information identification of the entity collecting the data identification of the uses to which the data will be put identification of any potential recipients of the data the nature of the data collected and the means by which it is collected if not obvious passively by means of electronic monitoring or actively by asking the consumer to provide the information whether the provision of the requested data is voluntary or required and the consequences of a refusal to provide the requested information and the steps taken by the data collector to ensure the confidentiality integrity and quality of the data Some information practice codes state that the notice should also identify any available consumer rights including any choice respecting the use of the data whether the consumer has

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/cp2 (2016-02-10)
    Open archived version from archive

  • CP3 | Markle | Advancing America's Future
    brand sponsor and affiliations and other packaging For example if a Consumer Access Service advertises itself as safe or private or secure such claims can be presumed to help shape consumer expectations more so in many cases than the notice of policies Choices should be meaningful All of the recommendations in CP2 Policy Notice to Consumers regarding clarity of language apply equally to consent mechanisms Consumer Access Services must spell out clearly the consequences of each choice Layered electronic notices which afford general notice with links to more detailed information may be a useful tool to provide the appropriate level of explanation for consumers to make meaningful granular choices Consent should be easily amendable and revocable To the extent possible consumers should have the ability to change their consent preferences at any time It should be clearly explained whether such changes can apply retroactively to data copies already exchanged or whether they apply only going forward Appropriate consent is contextual For example it s reasonable to expect that a PHR offered by a retail pharmacy chain would include a registered user s history of prescriptions filled through its stores However the consumer may not expect that the pharmacy would obtain non medication information about the consumer from other entities without obtaining independent consent Similarly a consumer might expect a provider based PHR that offers secure e mail with clinicians to have those communications imported into the provider s EHR but may not expect the publication of those communications in a journal article without specific consent Choices should be proportional The detail of a consumer s consent should be proportional to the sensitivity of the data its uses and disclosures as well as the sophistication of the consumer 4 Consent mechanisms should focus on reasonable expectations of an average consumer Consumer protection law provides a framework for determining whether consent for a given practice should be general or independent A key question in consumer protection cases is whether based on the company s overall actions and relationship with consumers a reasonable person would be unaware of a practice in question Therefore the general standard for independent consent centers on a reasonable consumer s expectations and is rooted in the principle that choices be proportional i e the more sensitive personally exposing or inscrutable the activity the more specific and discrete the opt in Based on the service s overall product and packaging and not just what is listed in the general privacy policy and terms of use reasonable consumers would expect to be asked specifically about a given activity then an independent consent mechanism should be provided 5 Recommended Practice The general principle is that consumers should have meaningful choices spelled out in an understandable way Consent mechanisms should set forth all collections uses and disclosures including the reasons for such uses and disclosures Consumer Access Services should obtain the consumer s agreement prior to any collection use or disclosure of personal data Data collections uses or disclosures of personal information that could be particularly sensitive or unexpected by a reasonable consumer or any that pass the user s personally identifiable information to unaffiliated third parties 6 should be subject to additional consent and permissions i e independent consent which should be obtained from users in advance of the use or disclosure The tables below provide an example for how these principles could be put into practice for a variety of information that may be collected used or disclosed as part of a PHR or consumer data stream We acknowledge that there is considerable burden both for back end systems and for consumers navigating a user interface to highly granular permission sets Some consumers with an established trust relationship with the service may be comfortable forgoing the opportunity to give specific consent to specific uses and disclosures Others may prefer to give specific consent to each type of requested use and disclosure It may be appropriate in some cases to provide consumers with default settings and the ability to indicate whether or not they wish to exercise consent more or less granularly Any default settings should bear in mind the reasonable expectations standard described above and should clearly spell out the basic consequences of either accepting the default settings or changing them Because appropriate consent is contextual to a given relationship between a Consumer Access Service and the individual consumer the table below is provided for general guidance Whether an organization is covered by HIPAA as well as what types of information it is sending to or receiving from a consumer application will have some bearing on the appropriate approach to consumer consent See CP1 Policy Overview for a discussion of HIPAA coverage When a service or application seeks to It should Collect or use identifiable information 7 directly from consumers Provide adequate notice to consumers of practices used regarding personal data Notice should include what information the service collects the purpose for which it is collected whether subsequent transactions of the same type will be covered under the initial consent how long the data will be stored etc See CP2 Policy Notice to Consumers Obtain consent from the consumer prior to collection or use of such data Collections or uses that would be unexpected by a reasonable user should be subject to additional independent consent which should be obtained from users in advance of the unexpected collection or use Collect or use indirectly identifying information 8 about consumers All of the above plus Set forth in policy notices all collections of indirectly identifying information and the purposes and uses of such collections Obtain consumer s independent consent prior to disclosing to unaffiliated third parties any information that can be directly or indirectly identifiable to an individual See CT4 Limitations on Identifying Information Collect or use identifiable information about consumers from unaffiliated third parties All of the above plus Obtain the consumer s consent prior to collecting or using information about the consumer from unaffiliated third parties Use an independent consent

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/cp3 (2016-02-10)
    Open archived version from archive

  • CP7 | Markle | Advancing America's Future
    between consumer data streams and business data streams to ensure that data captured or stored in consumer applications are not used as a basis for discrimination Our Work Group recommends that all network participants treat consumer data streams distinctly with higher levels of protection than existing business streams of health data This practice area recommends tough language to bar discrimination or compelled disclosures such as when the consumer s authorization for release of data is required in order to obtain employment benefits or other services Discrimination It is important to recognize that consumer data streams and networked PHRs may lead to a commingling or at least co existence of data from a variety of sources including the consumer It would threaten the consumer s trust in the entire network if the PHR were used as the source of information no matter its origin that affected an underwriting or employment decision The Connecting for Health Common Framework policies for health information exchanges prohibit use of information for discriminatory purposes 2 Similarly employer groups have publicly stated that they will never access individually identifiable information generated and stored in the PHR services that they offer to their employees Recommended Practice The preferred practice is to guarantee that none of the information made accessible to or from the consumer s application that is none of the consumer data stream can ever be used to discriminate against consumers In addition to complying with all anti discrimination laws and regulations all entities that access information in a consumer data stream should make public statements and develop internal practices against using information in consumer data streams for purposes of discrimination When appropriate Consumer Access Services and PHRs should include anti discrimination clauses in their contracts with partners The best means of preventing information from being used for discrimination is to put in place strong policies and access control procedures It is noted that some organizations particularly HIPAA Covered Entities such as health plans and self insured employers collect personal health information to perform their business operations i e as part of the business data stream as well as offer Consumer Access Services In addition to complying with all anti discrimination laws and regulations such organizations should use prudent practices such as implementing a firewall between consumer data streams and business data streams in order to prevent even the appearance of being able to use information in consumer data streams for purposes of discrimination Compelled Disclosures According to the chair of the Subcommittee on Privacy and Confidentiality of the National Committee on Vital and Health Statistics Each year as a condition of applying for employment insurance loans and other programs millions of individuals are compelled to sign authorizations permitting employers insurers banks and others to access their personal health information for non medical purposes These authorizations are nominally voluntary individuals are not required to sign them but if they do not they will not be considered for the particular job insurance policy loan or benefit In addition

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/cp7 (2016-02-10)
    Open archived version from archive



  •