Data Protections and Privacy (Preliminary White Paper Draft - charts removed)

 

There is a lot of specific and different kinds of data associated with a person’s health and welfare, which ranges from “general public access” to “very personal and private medical, identity, and financial” information. This data needs to be updated and shared, while still being protected and tracked, across many different individuals and groups, using unique identities and access permissions for each entity trying to access or update data.

 

Depending on our stage (or current condition) in life, different types of our data can be accesses and may even be controlled by different people. For example, the very old, injured, or young may have others manage their information and health, while in other cases, individuals may want to control their own information, and/or have an individual or organization “back us up” or help us.  

 

This is already done in a wide variety of ways based on individuals and their changing situations over their lifetimes. The System takes these aspects into consideration in its design and implementation. What the System does is to help facilitate and expand this concept, while allowing better protections to update and share information where it is needed, for an individual’s better health and wellbeing. The System looks at the many roles that people may have with each other and then creates access rule templates that make it easy to define and manage the relationships and the data that is shared between them.

 

Since this System is based off of “objects”, this concept also extends past individuals to other “objects” like equipment, buildings, departments, rooms, etc. Each object can have its’ data shared, protected, tracked, and managed based on an individual or role that has a relationship with that object.

 

Some examples:

• A minor is managed by a parent or guardian that controls their Information and Healthcare

• An Individual might be severely injured, sick, or disabled and need assistance from a family member, friend, or advocacy group to help them

• An individual may live alone and wants to have a backup in case of emergencies

• An elderly person may want (or need) to have some of their health and welfare needs handled by others

• A nursing or facilities department needs (individuals, tasks, rooms, equipment, etc.) to manage their needs across their staff and interact with other departments

• A Call Canter may be responsible for certain aspects of individuals’ health and welfare needs (monitoring the individuals and their homes, arranging for services, making sure things are being done and taken care of, etc.).

 

The System uses several different methods to populate, protect, access, and manage data. These include “Authenticated”, “Registered”, “Push”, and “Pull” methods.

• The “Authenticated” method, is a standard login/password authentication into the System that provides direct and specific privileges/access to different parts of the individual System and Accounts within it. This is similar to logging into a System (Application, Web, or Server) and then being able to perform different functions that you are allowed to access.

• The “Registration” method, uses well defined Object/Interfaces, which are setup when a device or service is “Registered” and then allows them certain permissions to communicate, access, and update data between each other. These are primarily used for system services, applications, and devices within and between Systems.

• The “Push” method, is fairly simple, where certain events, alarms, and data, can be set up to be automatically or manually transferred to a specified individual, application/service, device, etc. These would commonly be things like email or SMS/MMS (w/wo attachments), fax, or other common independent data transfer methods.

• The “Pull’ method is were an object (“individual” or a “role” within a System (or Cross Systems)) wants to access (or Pull) data from a System. This is an initiated action and this method requires setting up identity, authentication, and access methods to populate, protect, access, and manage data.

 

Some examples of Authenticated Access:

• Logging into a System and/or Account using an authenticated username/password using a Phone/PC/Tablet APP (through an APP, Web Interface, and/or network service) and then being granted access to information and functions based on their individual (and any assigned role) profiles

 

Some examples of “Registration” access

• A device is authenticated and registered with a System (as well as possibly an Account) to be a trusted object with certain permissions for assess between different roles and Systems. For example, the device can update the measured data for the individual (or other object) in the data space assigned to it on the System/Account. Going the other way, the individual can do updates on the device

• A Personal Service Provider needs to update information or billing from themselves, and the client needs to update their profile for them

• An Application needs to access certain data collected across different to be able to do analysis and presentations for an Account and/or System

 

Some examples of “Push” Data to Individuals, Roles, Systems, Services, Devices:

• Scheduling Data and Alerts to be set up, reminders, and/or escalations

• Errors, Events, and/or Alarms from devices 

• Analysis of Data received that might require an alert or event

• Triggered events (e.g. an event that has, or has not occurred when expected)

• Sending and responding to Alerts through txt

• A Medical Report or Bill sent to a System or Acount

• A question to a Health Professional

• Questions and an data in preparation for a Medical examination

 

Some Examples of “Pull” Data from Individuals, Roles, Systems, Services, Devices

• Getting the Public Identity Profile from an Individual through a RFID or Camera Scan

• A Medical Professional or Insurance wants to Pull certain data from one System to another

 

*** Authenticated Access Method ***

The Authenticated Access method uses standard login usernames and passwords for people (or applications/machines) to log into the System. This would include newer authentication methods such as a card, fingerprint, picture password, voice, etc.

 

When an individual (or other object) is logged into a System, they have an account and profile that provides them with access to their account (tools and applications associated with their specific function within the System).

 

They could also be assigned a “Role” at the System Level, which would allow them access additional parts of the System and other Accounts, as well as be used for notifications of certain events that occur within the System and/or other Accounts. Roles can additionally provide additional auditing and error prevention in the System, by allowing a user to switch themselves to a role that best defines what they are doing at the time. There is more information about auditing features in other documentation, and about Roles later in this paper.

 

Optional Remote Access is a concept where an outside organization could access a device within a System (e.g. Technical Support or a Device company going through trials). These outside organizations can be set up to have data automatically/manually sent to them (Push method), or be setup to get certain approved information (Pull method). They can also be set up to allow them to actually gain access to the specific device through a remote login to the System or Device. This would restrict them to the specific device, and certain data associated with the device on the System. Remote Access would be set up to be turned on or off, and could have generated one time passwords.

 

*** The Registration Method ***

 

Registration provides two valuable features to the System. One is the well-defined Object/Interface that protects and manages data between different registered entities. And the other is that data can be stored and accessed in known formats and locations so it can be properly updated, combined, analyzed, and used within and across Systems. This registration process allows the System to be able to have a full understanding all compliant and partially compliant service and device information no matter who develops them, as well as provide them with services they can use to make it easier for everyone to use and maintain the different devices, APPs and services. 

 

It is envisioned that a “certified” APP, Device, or Service would be pre-checked by an interoperability lab to make sure that it passes all of the security verification for the specific permissions that it would have. When they are being registered, the person registering the entity will be asked if they will grant the permissions that it is requesting. This is very similar to accepting the permissions requested by an application when you install or upgrade an APP on a Smartphone or Tablet.

 

Device Specific Registration

 

Device Registration is the method of setting up, updating, and defining different types of access between the System and a Device that is registered to the System.

 

At the top level, devices are defined using a Device Category, Manufacturer, Model, Name, Electronic Serial Number (ESN), and Subtype(s). This makes them unique, as well as provide a standard template of categorical information on the type of services and data are associated with them. This provides them with a unique data name space to store their data in, as well as being able to access and share data associated with a specific type (or subtype) of any device.

 

For example, there could be multiple devices supporting the same type/subtype functions, and you want to use a specific one or the data associated with that one. You may also want to compare data from two devices that support the same type/subtype, or you want to be able to easily replace one device with another, but still have easy access to the old data.

 

The System assumes that a single device can support one or more device capabilities (measurement or service) which are called subtypes. Smartphones are examples of devices that can perform many different functions (e.g. pulse, activity, visual diagnosis, etc.), which is accomplished through built in functions or applications using their basic capabilities.

A Device (or HW and/or SW Gateway that provides compatibility for partial and non-compliment devices) can be registered with one or more Subtypes. A Subtype is just a single measurement that can be made by the machine, and/or it may have the capability to measure analyze several different measurements and provide a combined result.

The device can then be registered for the specific System attributes associated with the device, and then register one or more different “subtypes” (measuring, monitoring, and/or analysis) that it can perform. Each device and its associated Subtype(s) are unique, (e.g. blood pressure, pulse, respiration, blood O2, etc.), and they have their own unique name space to store information associated with the main device and each of its subtypes.

 

A Device can be assigned to a System and/or one or more Accounts within the System. Once the data is stored on a System and associated Accounts, it can be set up to be retrieves, analyzed, or shared within the System and across other Systems. then be able to update and modify data within and across Systems. Having unique System, Account, and Subtype allows for simple searches for specific data across one or more Systems and Accounts.

 

The data (or a summary analysis of data) can be filtered and shared as needed across a wide variety or different individuals and groups (the individual, a care giver, a medical professional, a call center, or even organizations tracking trends within an area like the CDC/WHO). A detailed list of interactions is available in another paper.

 

Register System Services

 

A System Service is a general service used by one or more Applications on a System. They can exist on a local or networked server, or on a personal device such as a PC, Tablet, and/or phone. If you have used an Android OS device, you have probably noticed that when you are using an application and select an action, you are given the choice of two or more different options that can provide the service for you. Examples of these include scanning, mapping, navigation, web browser, emailing, and file format displays. Some of the new System Services could include medical image recognition services, scheduling, escalations, role management, gateway interface services, data type storage and retrieval, graphing, and reports.

 

This is a standard feature of Object Oriented Languages. Basically a Service is a well-defined Object that can be registered in a System, and as long as it agrees to provide certain capabilities, they can provide that service for any other application in the System that needs that specific System Service.

 

The System uses existing System Services that are commonly used today, as well as adding additional System Services to provide additional capabilities in support of the features envisioned for this Initiative. These Services will support Applications on the System, allowing developers to leverage off these System Services to provide a lot of their functionality, and not have to build, test, and support them themselves.

 

 

Registering Applications

 

Registering (installing) Applications is very common on Servers, Phones, Tablets, and PCs. Many require specific interaction with the System and other Applications to provide permissions for them to be able to use them on their System. The System will potentially have to expand this concept to allow Applications access to specific types of information and tools on the System, which are not currently defined.

 

Since Applications are allowed to provide System Services, there would need to be safeguards into the System to prevent, unscrupulous applications from trying to provide certain System Services to get information about the person.

 

For example:

• A general Diagnoses program, may need to be able to access data that was collected by multiple devices or applications

• Being able to store, update and share information between a Personal Services Provider and an End User

Applications may also have dependencies for certain System Services or versions of other Applications and Devices that they may share or use information. There are several design features to help in this area.

• Crete generic interfaces that can support future applications and devices

• Work to identify and design in generic data types and interfaces that limit changes that would require a lot of dependencies between different OSs, devices, and applications in the future

• Work to support backward compatibility

• Allow for the definition of any specific OS, device and Application dependencies that can be displayed and selected by the user when upgrading an application or device

• Work to build a “Store” that knows and understand s the Applications and Devices so that the end user knows what they need, and can easily restore their Applications if they get a new device

 

Register Personal Services

 

Personal Services are provided through Applications. The System envisions having some standard and common Applications to provide Personal Services, so individual services provided through these applications need to be registered and provided certain permissions.

 

Services are a little different. Services can share a common Application, but provide different services or even common service types, but need to have different levels of agreements, access, and trust. 

 

Some of those differences include:

• Having formal agreements

• Billing, payments, and approvals

• Scheduling and approvals for work)

• Ability to update or access information in the Individual’s Account (certain personal information, special instructions, status, measurements, escalations)

 

For example, a person/service that goes to a person’s house, may need access to specific information about a person, which would not be provided to other services, or services that were not approved and agreed to. Another case is the sharing of information between the Personal Service Provider and the End User. There could be contracts, schedules, approvals, billing, payments, and feedback. There could also be things like data and reports sent to and from a Personal Service like a Doctor or Ask a Nurse.

 

Basically a Personal Service would have a Master Agreement and would supply one or more subtypes of service, and each one would be registered with its associated parameters.

 

*** The Push Method ***

 

The “Push” method” basically sends data to a designated location which can be an individual, application, and/or data service. It is envisioned to use this method to pass data to a System and/or Account. This can be accomplished in many different ways either directly or through Object Interfaces that can pass voice, text, data and application links, pictures, and/or attachments, as well as receive responses from the receiving parties

 

• Direct access through registered and approved Object Interfaces through an APP

• Text (SMS and MMS) w/wo attachments (directly or through a provided Object Interface)

• Email w/wo attachments (directly or through a provided Object Interface)

• TBD - There is nothing stopping the System from also using automated voice, scanning, and fax

 

Many of the Devices, Services, and Applications will have their own unique set of data as well as common types of data. They can pre-define actions when certain events occur, which can be modified by the end-user. These will all be set up as part of their registration, with common views/interfaces for adding and changing who is notified of the data they manage. 

 

Some examples of events that may require some common or customized System/Account responses

 are…

• An update is made to the Application or its operational settings

• A note is added or modified

• Access rules have been changed

• An alert has been determined form one or more events

• Data has been collected

• A transfer of data was made

• A maintenance action is required (calibration, repair, replace consumables, etc.)

• Scheduling, Payment, Billing, approval actions

 

For Individuals (and the Roles they are assigned to), these are typically just lists of general email and phone numbers, where information should be sent. There can also be machine to machine interfaces defined within and between Systems.

 

The System can support specific Roles associated with other Systems by providing the System ID and username or role of the intended recipient. A Role is just a predefined function for a System (e.g. System Administrator, Account Administrator, Nurse, Nurse Supervisor, Facilities Department, and Primary Doctor). There are common predefined Roles in a System/Account, but the System/Account Administrator can add additional ones and assign them to individuals. The System can be “shift aware” and can grant access based on the individual(s) responsible for that function at the specific time, and roles can be assigned to other roles, to reduce the amount of entry (e.g. a System Administrator, could also be the Account Administrator as a default).

 

For Applications, Devices, and Services, (AKA machine-to-machine interfaces) these are their own electronic addresses with defined formats and instructions. This is important to be able to transfer data to other Systems, without knowing specific recipients associated with another System. <See some of the services and devices under the GUI Demo Tab for examples>

 

During the registration of the device, application, or service, some of the data would need to be manually entered (Individuals and Roles), while other data sent to Roles, Applications, and Services can have defaults, and only require conformation. 

 

The following table lists some of the Events that can be sent to a System/User, System/Role, email, phone, service, application, or device. As previously mentioned, this could be through email, txt (SMS or MMS), Application alert, and/or a data packet. Along with the notification, additional information is sent associated with the event, which is the subject of a different paper. Each of these events is automatically event/audit logged in the System, but can be elevated to alerts/notifications to others as desired

 

The different Actions/Alerts supported by the application, service, and/or device would be included in the installation and part of its profile. The end-user can leave the default value, and/or enter the email/phone/address of the recipient(s) to be listed.

 

*** The Pull Method ***

 

The pull method is basically just pulling data either directly or through a request, based on their permissions to access that data.

 

There are some basic elements that need to be defined so that the data can be stored, categorized, protected, shared, and managed within and across Systems.

• Create specific Systems that Individuals (or other objects) can be associated with

• Create specific Identifying ID(s) for an individual (or other objects) with a specific System

• Create Authorities that can create and assign unique System (and in some cases individual Object IDs) so they can be linked

• Create defined categories of data that can be assigned specific access within and across Systems

• Define Roles for individuals within Systems for access and control of the data

• Create Access Control Lists (ACLs) to assign assess for an object, its different categories of data, and access within and across Systems

• Create an authenticated way of passing data within and across systems

• Create a logging and auditing capability to track data access and changes in access permissions

• Leverage on HIPA Certified Cloud Storage Systems

 

Access within a System is hierarchical in nature. Data access can be granted to an individual or role at the System level, and it can then be accessed by at the Account levels, without specifically identifying the access for the Role or Individual at the Lower Account Levels. Lower Account levels can be set up to block upper levels through their own access control overrides.

 

Identifying a System

 

Each System is assigned a System ID by an authorizing agency. The structure of the System IDs support a lot of flexibility, allowing larger companies to create their own sets of System IDs for  a wide variety of different purposes. These can include Systems for different locations, departments, and locations, as well as for different purposes like operational, training, and development Systems. For individuals and some smaller organizations, they may only need a single System ID that they link their users to.  For large Organizations with operating in multiple countries or diverse operations, they can uses multiple high level System ID Structures and link them together.

 

System IDs are also defined to support research by providing generic information about System IDs that can be used to identify data for a wide variety of data analysis, without specifically linking the data to a specific identity of an individual.

 

The following table shows the Structure of a System ID, which is composed of 15 Alpha Numeric Characters.

• Country Code - (2) Alpha Chars - Country Codes - Standard two character Country Codes (e.g. US, CA, GE, AU, FR, etc.)

• Issuing Authority - (2) Alpha Numeric Chars – TBD - An issued two char identifier for an Issuing Authority, which would be unique per Country Code, while allowing certain authorities to support more than one country. They are likely to be assigned to regions within a country

• System Category - (2) Alpha Numeric Chars – TBD - A defined two character representations for different types of organizations (e.g. hospital, Individual, pharmacy, retirement home, bio tech, insurance, pharma, government, etc.)

• System ID - (4) Alpha Numeric Chars – TBD – A defined four character designator for the System – e.g. representing a company/organization. All System ID designation at this level and above is set by the Issuing Authority

• System Type - (1) Alpha Numeric Character – TBD - A defined one character designator for the “System Type” or “Use” (e.g. Operational, Training, Demo, Prototype, Test, Development). It is defined at this level, so that different Types of Systems can be mirrored with Operational Systems

• Subsystem ID - (2) Alpha Numeric Chars – TBD - An Issued two character designator, typically for the location and/or division of a company/organization. The two characters are hierarchical, allowing further Organizational and Access capabilities.

• Unit ID - (2) Alpha Chars – TBD - An Issued two character designator, typically for a unit, department, or organization within a company/organization. The two characters are hierarchical, allowing further Organizational and Access capabilities.

 

 

 

The Issuing Authority would provide a ten character Main High-Level System ID that designates a System ID for a company or organization to use. The company or organization would then create and manage their own Systems associated with that Main System ID by supplying values for the “System Type”, “Subsystem ID”, and “Unit ID” fields. For Small Organizations and Individuals, the Issuing Authority could also create those fields, allowing Main High-Level System IDs to be split and shared. 

 

Sample Corporate Structure:

• “USATHSORGN” – High Level Main System ID (US – USA, AT – Authority for the System ID, HS- Hospital, ORGN – Designator given to that Hospital Organization)

• “O” Operational – System Type

  • “CO” Corporate Main – Subsystem ID

  • “CB” Corporate at Boston Center – Subsystem ID

  • “CS” Corporate at San Francisco Center – Subsystem ID

  • “HB” Hospital in Boston – Subsystem ID

    • “P0” – General Patients – Unit ID

    • “NG”- General Nursing  - Unit ID

    • “N1” – Nursing 1st Floor – Unit ID

    • “FG” – Facilities General – Unit ID

    • “F1” – Facilities 1st Floor – Unit ID

    • “FH” – Facilities HVAC – Unit ID

  • “HD” Hospital in San Diego – Subsystem ID

    • … Same or similar to “HB”

• “T” Training – System Type

  • … same structure for Operational System

• “E” Test – System Type

  • … same structure for Operational System “D” Demo – System Type

• “B” Development – System Type

  • … same structure for Operational System

 

Note:  It is assumed that these are all based on English Alpha Numeric Characters, as they are mainly just character representations for defining a specific System ID.

 

Identifying an Individual

 

A specific Individual (or object) occurrence is made up of a System ID and a User ID for that System.  A specific individual can have more than one occurrence (e.g. more than one User ID associated with the specific System). For example, an individual may check into the same hospital many times, and the hospital wants to keep the data associated with the visits separate. Another example might be that an Administrator of a System might want to keep two versions of data on an individual and share different occurrences of the individual (or object) with different Individuals, Roles, and/or Systems.

 

 

An example of an ID for a user would be:   USBBHSSCRPOAAAD-00231013

               System ID:  USBBHSSCRPOAAAD      Sample User ID:   00231013

 

Note: This is assuming that the Individual IDs within a system consist of Numeric Characters. If there was a desire to support alpha numeric characters in a local language, additional data space would be needed to other language characters.

 

Linking Multiple Object Occurrences within an System

 

Within a System, different occurrences of an Object (or individual) can be linked at a certain level.  Conceptually, it would be a basic table that defines different linked occurrences of User IDs within a System ID. 

 

For example:

• 00231013             John Smith

• 00246931             John A. Smith

• 00274398             John Smith

 

The System would log the activity, and perform some validity checks on the information about the different Individual IDs to make sure they were the same and provide feedback through alerts. Once linked, the data between the different occurrences could be viewed and/or analyzed, assuming the individual or Role has those permissions in each of the System/Individual IDs.

 

Linking Hierarchical Systems

 

Starting at the “System Type” field, different Systems can be linked together, to share data across operational modes, locations, and departments. This allows one or more locations and/or departments associated with an organization to be linked at a higher level.

 

Access is still bound by the Roles and ACLs at the lower levels for the individual trying to access the data. The advantage is that each specific location/department within an organization does not have to list each one separately, and by defining their System ID structure, they can set up some powerful ways of linking and separating different groups and locations.

 

For Example (using a “*” as a wildcard):

System Linkage Access  Sample Result

• USBBHSSCRPO****       R             Links all Operational Systems within an organization

• USBBHSSCRPOAA**       RW         Links all of the department’s/unit’s Operational Systems associated a location or division

• USBBHSSCRPT**A*        RWD      Links all of the Training Systems associated with specific departments/units across the organization

 

R=Read, W=Write, D=Delete

 

Cross System Linkage

Different Systems can also be linked to each other, which (TBD) can be set up on the side sharing or set up and authenticated on both sides. This only sets the highest level of System access, while lower level ACLs would still govern access.

 

For Example (using a “*” as a wildcard):

• USBBHSSCRPOAAA*      RW         USBBMLSTVPOAA**      Links all Operational Systems between a specific Hospital Lab and a contracted mobile Lab Service

• USBBHSSCRPTAA**        RW         USBBGVTYZRPAA**       Links the Training Systems between a Government Emergency Response unit and the departments at a hospital

R=Read, W=Write, D=Delete

 

Linking Individuals to another System

 

• USBBIDSCRPOAAAA: 00246931  Jill Davis’s System: John Smith  RW – based on Category or Special to USBBHSSCRPOAAAA: XYZ Hospital         Grants access to all direct organizations associated with the Hospitals to John Smith’s Data located on Jill Davis’s Personal System

 

R=Read, W=Write, D=Delete

 

 

**** Placeholder

Access is granted on a User ID, Type/Classification of Data, Role or specific identity of the individual(s) accessing it, and the specific permissions Granted to those individuals and Roles. Standalone Systems can have one or more User IDs associated with an individual (or other object) and can leave them separate or link them together.

 

Types of Roles

 

The System supports many different pre-defined, and end-user defined roles. The System defined roles, are used for data access and protections, as well as notification for default scheduled events and alerts. The table below defines those envisioned pre-defined roles, which can be assigned to users, or access for other Systems. Although the data is defined, a System Administrator can see who is assigned to what roles, and “switch roles” to see what a given Role has assess to.

• System Administrator    A person who administers a specific System associated with this Initiative. They can create accounts, assign roles, define access, and set up a number of System Applications, Devices, and Services at the System Level.

• Account Administrator  A person who administers a specific Account associated with a Specific System. They can view everything within the Account, and can set up a number of Applications, Devices, and Services at the Account Level. An Account doesn’t need to be an individual and could be another object like a piece of equipment, facility, or department.

• Guardian             Basically an Account Administrator for one or more specific accounts. You can be your own guardian, or allow someone else to share or manage the account equally. There is also a way of creating and locking in a ”my view”, allowing someone that is being cared for, as specific view into their Account (but not everything).

• Caregiver             A person caring for an Account (or multiple accounts), but do not have access to certain personal financial and health data.

• Health Professional         A trusted individual that can access certain medical information about an individual, access to certain applications, as well as the registration of devices between individuals.

• Medical Assistant             Similar to a Health Professional, but with restricted access based on their current credentials

• Admissions         Sufficient information about an individual to admit them to a medical facility

• Billing  and Payments Administrator       

• Insurance Administrator              

• Technical Support            With and without remote access

• Warranty Support           

• Manufacturer Support  Can also be used for trials

 

Additional end-user defined roles (and listed individuals) can be created and used for scheduled events and alerts, and in some ways they are provided access to data they need “by proxy”. For example, an individual getting an alert or notification of an event, would need access to the data associated with the notification. This specific data can be passed through a message or link, without the individual having access to all of the data within the defined data category.

 

Types of Data

 

The System is designed to support both Generally Classified Data, as well as Specifically Classified Data for special cases. This allows most end users, the ability to use defaults and simple assignments to manage their data security. It is not that the Specifically Classified Data is difficult to manage, it just needs to be specifically listed and granted.

 

Types of Data – General

 

The System is designed to create certain defaults for Data, as well as be able to walk people through their setup and review (through “Walk Me Through it”) to be able to setup and share data access and protections. The System is also designed to create warnings, audit trails, and optionally alerts for changes in an object’s data access or permissions.