|
||||||||||
| PREV NEXT | FRAMES NO FRAMES | |||||||||
See:
Description
| Packages | |
|---|---|
| org.tolven.admin | |
| org.tolven.app | Tolven-based applications can take advantage of a persistent menu structure provided by this package. |
| org.tolven.app.bean | Tolven-based applications can take advantage of a persistent menu structure provided by this package. |
| org.tolven.app.el | |
| org.tolven.app.entity | Persistent entities used by the user interface. |
| org.tolven.ccr | The structures defined in this package are an exact representation of the ASTM E2369-05, Standard Specification for the Continuity of Care Record. |
| org.tolven.core | Interfaces to core functions including creating Accounts, finding all Records for an account. |
| org.tolven.core.bean | [TBD] This will contain DAO classes that perform various functions from creating Accounts to finding all Records for an account. |
| org.tolven.core.entity | Contains the core entities used by Tolven software such as Account, HealthRecord, User, and Sponsor. |
| org.tolven.core.util | |
| org.tolven.ctom | |
| org.tolven.ctom.bean | |
| org.tolven.ctom.entity | Contains the core entities used by Tolven software such as Account, HealthRecord, User, and Sponsor. |
| org.tolven.doc | |
| org.tolven.doc.bean | |
| org.tolven.doc.entity | Contains Document-related entities used by Tolven software such as Invitations, CCR, and various transmittals. |
| org.tolven.gen | |
| org.tolven.gen.bean | |
| org.tolven.gen.entity | Contains entities used by Tolven software to generate test data. |
| org.tolven.gen.model | This package contains the classes needed to generate patient medical data. |
| org.tolven.gen.util | Utility functions used by test data generators. |
| org.tolven.process | |
| org.tolven.provider | |
| org.tolven.provider.bean | |
| org.tolven.provider.entity | Sequence generator for provider package. |
| org.tolven.queue | |
| org.tolven.queue.bean | |
| org.tolven.queue.entity | |
| org.tolven.security | |
| org.tolven.security.auth | |
| org.tolven.security.bean | |
| org.tolven.security.entity | |
| org.tolven.trim | |
| org.tolven.trim.ex | |
| org.tolven.voc.umls.rrf.bean | |
| org.tolven.voc.umls.rrf.bean.rrflist | |
| org.tolven.voc.umls.rrf.bean.splitter | |
| org.tolven.voc.umls.rrf.columns | |
| org.tolven.voc.umls.rrf.entity | |
| org.tolven.voc.umls.rrf.loader | |
| org.tolven.voc.umls.rrf.loader.factory | |
| org.tolven.voc.who.entity | |
| test.org.tolven.app | |
| test.org.tolven.app.el | |
| test.org.tolven.ccr | |
| test.org.tolven.security.key | |
| test.org.tolven.trim | |
| test.org.tolven.trim.xml | |
| test.rules | |
Tolven Health Information System provides access to and creation of standardized health-related information to all types of users.
[TBD]
Tolven functionality is exposed through a Web application, Web Services, and through JEE Session and Message Driven beans and falls into the following broad categories:
Keyword search, browse by classification, complex browse such as display alternate drugs.
Store, encrypt, and fetch whole documents. Also stores transformed documents eg each sharing of a doc is a new doc, pharmacy orders extracted from a document is a new doc. Infinitely distributable.
Generally partitioned by user group and thus distributable. Typically lists of information extracted from documents like appointments by day, patients matching cohort criteria, etc. Includes workflow tasks.
Distributable. Authenticate principals (people, organizations, systems). Triple ID links user ID to person identity to content. Without these links, data is meaningless to an intruder.
Component and source |
How Used |
E2369-05 Standard Specification for Continuity of Care Record (CCR) |
CCI document (XML) |
HL7 Reference Information Model (RIM) See |
Information Model |
Unified Medical Language System (UMLS)See |
Vocabulary Model |
Tolven operates as a typical web-based application and as such uses SSL as the basis for most communication with in the form on HTTPS for HTML and AJAX browser communication or as part of WS-Security for WSDL-based communication. Even HTML pages addressing anonymous users are protected this way.
[NEEDS MORE]
Authentication is provided by the JEE container in conjunction with an LDAP server. [TBD]
Tolven uses [TBD]
Privacy is a precious commodity which, unlike insurance for financial loss, is hard to "fix" if breeched. Tolven enforces privacy control without depending solely on information custodians "keeping secrets" or depending on limiting physical access to data. Physical security and keeping secrets are elements of Tolven's privacy mechanism, they are not the last lines of defense. At the core of Tolven's privacy strategy is limiting the connection between a person's identity and their HealthRecord(s).
Simply put, if identity information and medical data is separated, then the information has little value to someone seeking to access private information. And as long as these two elements don't come together, privacy is not breeched.
A password or similar credential, which is not stored anywhere by Tolven or known to Tolven, is required to connect the two halves. A user that shares a person identity with another Tolven user such as a provider, is doing so through a ManagedReference to that identity.
Technically, deployment is done as a J2EE EAR (and WAR). This makes most of the details of deployment routine once an application server is available. During deployment the O-R tool builds (or updates) the DB schema on the fly by using EJB3 entity definitions.
Three basic deployment models:
This section could also be called audit-ability or recover-ability. One basic approach handles all three.
The transactional core of Tolven is what we call a document metaphor which is not a real document but end users can think of it that way. Most important is that this represents a business “transaction”. The same mechanism used to store and queue CCR and HL7 data also stores mundane transactions like a preference changes. An extreme example of this transaction pattern is an entire UMLS vocabulary update. Everything is a transaction and is captured as a whole in the document metaphor. Each is given a unique ID. Once “submitted”, a document cannot be modified.
Any number of servers can be configured to accept these transactions and replicate them to at least one other server as a backup. So there is no reason for downtime in this area. As an immutable object, consistency is not an issue: Any copy of an object is just as good as another making objects like this a good short-term cache candidate.
Vocabulary is also relatively static and thus easily cached and replicated as needed for performance and availability.
Strong adherence to the arguably low-tech “transaction” approach allows the system to be taken off-line in a traditional sense while still providing read only access with provisional updates. This means that while in an off-line mode, transactions may be subject to processing a second time against a baseline version of data, similar to the way bank transactions are applied provisionally during the day and then again at night after a trial balance.
Thus, off-line should feel like on-line to most users. the only difference is that backend work is required to synchronize servers. This approach also allows the replay of transactions should something really go wrong. So, even in the most extreme cases, the system can be available near 100%, limited only by communication and computer hardware availability.
This low-tech approach reduces the need for expensive software that maintains fault tolerance in databases and application servers while still taking advantage of the readily available transaction (ACID) capabilities of most database products.
Although many healthcare queries and updates can be complex, response time must generally be very fast both for the public and especially the clinical user. There’s no single performance silver-bullet in the system, but rather an overall pattern of compact code paths, caching, and efficient use of resources.
Ajax helps performance on the client. In the database, many tricks are used. Data is pre-staged in the database (space sacrificed to gain time). A good example is in the classification mechanism. A drug like Aspirin is categorized as a “non-steroidal anti-inflammatory”. To make queries efficient, by avoiding expensive pointer-chasing, aspirin is also added as an entry under super-classes like anti-inflammatory drugs and even drugs.
Cluster load balance, fail-over, connection management, caching. Security is managed by the container and web-application configuration. Error logging and other services are handled by the container. Services can be monitored and controlled generically using the MBean architecture.
An actual human person seeking healthcare and/or the management of personal health data. While fundamental to the healthcare model, Tolven does not explicitly model a consumer as a database entity. Technically, a consumer is usually the "guest" accessing a public Tolven page.
The subject of a HealthRecord. A Person is often the player of a Patient Role or Provider Role according to HL7 RIM. From a health information perspective, Tolven considers a person as the person's identity, not the actual human. One human may have more than one identity in Tolven. Tolven makes no assumption about the uniqueness of Person identities. In fact, the physical separation of identity from information is a fundamental part of Tolven's security architecture. See ManagedReference.
Tolven believes that having a Person actively involved in the management of their own health record yields a very high-quality of uniqueness, much more so than any attempt by providers or the government to establish uniqueness through Master Person Index schemes and Record Locator Services. For this reason, a count of Tolven HealthRecords in Personal Accounts (ePHRs) can be considered a reliable count of "subjects" for research purposes.
ASTM CCR: Person may be the same as CCR's "Actor".
HL7 RIM: Person is a subclass of org.hl7.rim.LivingSubject. The org.hl7.rim.Patient Role subclass is played by LivingSubject, not the narrower org.hl7.rim.Person.
Tolven: A HealthRecord can also be for an org.hl7.voc.EntityClassCode#Animal Although this is not specifically exposed in the first version of the application.
A healthRecord (ePHR or eCHR) is maintained within a single TolvenAccount. Thus, one human person may have many HealthRecords with only one of them being a Personal record and each provider holding a provider (eCHR) record for that person.
Tolven makes no attempt to consolidate or link HealthRecords together automatically. However, linking usually does occur over time. Think of a personal HealthRecord as the "master record" for an individual. Over time, communication with various providers, agents, and other participants accumulate in the Personal HealthRecord. The net effect is that the Personal HealthRecord becomes a very accurate and up-to-date Master Record.
HL7 RIM: HealthRecord is not necessarily the same as a Patient and so Tolven models them separately. However, in a provider setting, when appropriate for a given account, each Patient can be given just one HealthRecord.
A User is associated with one or more Tolven Accounts. This User object is not used for authentication, which is done by the application container using LDAP. Instead, a User object is simply associated with an LDAP Distinguishing Name. What this User object represents is the User's participation in the Tolven database as the author of documents and participant in one or more Tolven accounts.
When a user logs in, the User selects the desired Account and thus only ever works with one Tolven Account at a time.
If the user changes his or her username, such as when changing eMail accounts, a new User record is created. This is because Tolven can't always be certain of the relationship between a set of credentials and a real human. While this creates a bit more database clutter, it also ensures that potential identity ambiguities are accompanied by unique user objects. In particular, it is quite possible for eMail addresses to be reused by different persons. Tolven accounts for this as follows: Say a consumer establishes a Tolven account with userid boney32@aol.com. In time, this consumer changes her eMail address and thus her Tolvern user ID to Marge.Swanson@wilco.com. Tolven drops the old address from LDAP. Later, someone else grabs the ever-popular boney32@aol.com email address (Tolven has no control over AOLs mail account naming.) That second person creates a Tolven account using the same aol eMail address. To avoid an unintentional identity theft, the ID of the User account is stored in the LDAP entry. The result being that two different people presenting with the same eMail account (usually at different times) will have separate Tolven User objects. This technique also reduces the risk of intentional identity theft.
A User may have access to more than one Tolven Account such as when a physician belongs to two practice groups (two unrelated provider accounts) and has a third, personal account. A person may also have more than one active username such as a personal eMail address and an eMail address at work. This is usually not needed since Tolven manages the difference between personal and work through account assignment. However, in cases where Tolven federates identity with a large organization's own LDAP, multiple User IDs for Tolven may be unavoidable.
In summary, Tolven Users are permanent whereas LDAP entries may come and go over time. The ID of a user object is never reused. The following summarizes the interactions between LDAP and User object in various situations:
| Human Activity | Object | Action |
|---|---|---|
| Register for a Tolven Account | LDAP | Create username and password and ensure uniqueness. Only one user at a time can have the same UID. |
| User | Create new User record and thus assign a new tolven User Id. | |
| Send activation email to registrant's email address. This verifies the eMail address. If not verified in X hours, the entry is removed from LDAP and the User object is flagged as inactive. | ||
| Click Activation Link in EMail | User | Flag User as Active thus activating user account. |
| Login to Tolven | LDAP | Validate username and password in LDAP |
| User | Match on LDAP UID active flag. If user is in activating state, user is advised to complete activation process (or start over if the eMail address was incorrect). | |
| Change Tolven Username (EMail address) | LDAP | Create new LDAP entry, previous LDAP entry also remains |
| Send re-activation email to registrant's new email address. Also, send advice to old eMail address for security purposes. | ||
| Click Activation Link in EMail sent to new address (User must login under new username) | User | Change state to Activated |
| AccountUser | Link new User to existing account. Deactivate previous AccountUser link(s) | |
| LDAP | Add new user ID to LDAP thus activating new account. Also, remove previous Tolven User ID. | |
| User | Deactivate previous User object. | |
| User attempts to login with new credentials prior to clicking Activation link | LDAP | User and password are valid: User authenticated. |
| User | ID from LDAP does not match a valid User object (it would be null at this point): User is rejected with advice to complete verification process or start over from previous, still-active LDAP entry. |
The net effect is that Tolven may, over time, have more than one User object with the exact same DistinguishingName and therefore this attribute is no unique constraint in the database for DN.
Note: Password and other User demographic data are handled by LDAP, not the user object.
The following is a sample of the Verification message sent to the (potential) new User.
From: activation@tolvenhealth.com
To: tina.sams@hillside.net
Tina,
Your new Tolven account is just one click away from being completed.
Please click on the following link or paste it into your browser address box:
https://activation.tolven.com/verify.jsf?id=W722Q1A
You will be asked to login using the username and password you established
during registration.
Thank you for registering with Tolven,
Tolven Activation Department.
PS: Tolven never sends personal information via general-purpose eMail.
Keep your password secure. Tolven will never ask for your password via
eMail or on the phone.
|
A similar message would be sent for a re-activation, when the user changes their eMail address. As described above, a second message is sent to the previous, still active, eMail address:
From: reactivation@tolvenhealth.com
To: tina.sams@hillside.net
Tina,
We are sending this to confirm that you are changing your eMail address as follows:
christina.sams@brookstone.net
If this is correct, just respond to the eMail sent to that new address.
There is no action needed in this message.
If your new email address is incorrect or you did not request a change to your
eMail address, please click on the following to cancel the change and reset
your account back to your previous, still active, user ID.
https://activation.tolven.com/cancel.jsf?id=1TQ91711
You will be asked to login using your previous username and password.
Thank you,
Tolven Activation Department.
PS: Tolven never sends personal information via general-purpose eMail.
Keep your password secure. Tolven will never ask for your password via
eMail or on the phone.
|
Note: If the user does cancel the change by clicking the link in this message, but the user, or an imposter, has already activated the new username, Tolven will ask if the user suspects foul play and if the answer is yes, the Tolven security department will be notified.
An Agent is a User of a Tolven Account. Such a user can establish a record for anyone or an Animal for that matter. (Even fictitious people although such persons may have trouble getting insurance coverage!) When an Agent creates and manages a HealthRecord for him- or herself, that is what most understand as a Personal Health Record. When a User creates a Personal HealthRecord for someone else, that User is considered an Agent.
Tolven supports changing or revoking agency depending on the way agency was initially established and how it is intended to be changed.
Note: An Agent is not the same as a Provider (providers interact with their own HealthRecord for the patient, not with the patient's ePHR.
It is up to the recipient to determine the authenticity of an agent acting on behalf of a communication regarding a HealthRecord. For example, if Mary Mom requests an appointment for Karl Kid, the provider has no way of verifying, via Tolven, that Mary Mom is authorized to act on behalf of Karl Kid or that Mary is authorized to received communications regarding Karl.
See Referral Account
An Account holds a collection of zero or more HealthRecords and related data such as insurance for personal accounts and Patient Data for Provider accounts. An Account can have SubAccounts, usually for larger provider accounts. A Tolven account can have one or more Users. One or more of those Users will be an AccountAdministrator.
There are several basic Account Types:
SubAccounts can also have an AccountType which can be different from the parent Account. For example, it would be common for a Provider to have a Referral SubAccount to hold newly referred patients. The same provider could also have a Provider Account for those Patients being cared for by that provider.
The capabilities of each of these Account Types can overlap. For example, a large family may require similar features of an Agent account and smaller Provider accounts may not need all the features of a large enterprise Provider. Therefore, AccountType is actually just a preset for a number of Account preferences that can be individually controlled by the AccountAdministrator.
SubAccounts can have users and records just like the parent (or top-level) Account. However, SubAccount users are always constrained to be a sub-set of users of the parent account. Thus, the top-level Account must have all users appearing in any SubAccount under that account.
Personal accounts usually don't need SubAccounts.
When a SubAccount is created, an irreversible decision is made to make it a subset SubAccount or an independent SubAccount. A subset account means the account must contain a sub-set of the records in the parent account. For example, a nursing unit would always be constrained to patients of the hospital. A practice or clinic may have SubAccounts with specific kinds of patients selected from the clinic's patient roster. In any case, removing a record from a SubAccount will require its removal from nested SubAccounts. In all cases, the root account contains an implied list of all records that exist anywhere within the account. Only top-level administrators have access to these patients. An independent account can have new HealthRecords created by the administrator(s) of that SubAccount. Examples of independent accounts include ReferralAccounts, clinics within an organization where each clinic maintains a separate record for each patient. Or a psych hospital that maintains independent records.
Users of a parent account can be allowed access to all records in the SubAccount. Or, if the subset setting is true, the SubAccount can have a separate list of users. The subset setting is meaningless for the top-level account.
The administrator of an account may grant administrator permission to any users of the SubAccount. In so doing, the SubAccount Administrator can do the same with any sub-SubAccount. Also, any Administrator of a parent account can administer any SubAccount below it, no matter how deeply nested.
While the number of users in an Account is restricted as one goes further down an Account tree, this is not necessarily true for HealthRecords. It would be common for a top-level administrator to create a minimum of two SubAccounts: one for records he/she manages and one for records managed by SubAccounts. For example, the top-level administrator may have records in one SubAccount they maintain for testing and training purposes which most users can't access. The second SubAccount, with many more users, contains all (real) patients of the provider.
A Referral Account is a special type of account. Normal accounts hold HealthRecords belonging to that account whereas a referral account holds HealthRecords belonging to another account. HealthRecords in a referral account are virtual in the sense that it is not a separate record nor a snapshot record. Rather, it is a view into the source record. This view may either be partial or complete. A provider's Referral Accounts renders the HealthRecord read-only. f writeable, then when a user of the referral account updates the record, that user is actually updating the original record. The HealthRecords in a referral account are revocable by the referrer. Revocation is either by implicit action of a rule established by the HealthRecord holder or by explicit action of the HealthRecord holder. In this regard, the user of a referral account has no control of the revocation process or its timing.
Referral Accounts can also be used for Agent arrangements where revocability is needed. For example, an individual can ask someone to access their record, perhaps to record certain observation. The holder of the HealthRecord does not want the agent to be a part of the account and holder of the record may want to revoke the agent's access to the record at some point in time.
A term used by Providers to refer to the people that the Provider cares for. A single human person may be a patient of more than one provider and thus, from a data perspective, has more than one Patient object. Tolven distinguished between a HealthRecord and a Patient Object. The following table summarizes the relationship between these concepts and Encounter.
| Setting | PatientObject | HealthRecord | Encounter** |
|---|---|---|---|
| Clinic | One per person. May be shared with hospital depending on policy | May have one per clinic* | Each patient will have one per visit |
| Hospital | One per person. Each hospital in an IDN may have a separate patient object. | Some hospitals create a separate HealthRecord per visit, otherwise one HealthRecord per patient.* | Each patient will have one per stay |
| Consultant | Referring clinician may have a patient object which may or may not be recognized by the consultant. | Consultant views and/or updates HealthRecord of referring clinician | Usually no unless consultant establishes a separate patient object, HealthRecord, and encounter. *** |
| Personal | Not applicable | Usually one per person | No (provider establishes encounter) |
| Agent as health record owner | Not applicable | Usually one per person, not duplicated by personal record. For example, mom and dad keep a HealthRecord for a child. Child doesn't have a separate record. | No (provider establishes encounter) |
| Agent not owning health record | Not applicable | No separate healthRecord. Agent views HealthRecord of individual. Example: Mom (agent for child) goes on vacation leaving a friend (this kind of agent) to watch chronically ill child. | None |
* In some cases, an institution may combine lab, radiology, and other ancillary reports into a single record while keeping separate physician and surgical records per clinic or hospital stay.
** Encounters can actually be complex when related to episodes of care.
*** If a patient is referred to another provider (consultant), that act does not, in itself, create a new patient record or suggest that the consultant has a new patient. The consultant can take an action to create a new patient (or reference an existing patient) and optionally insert part or all of the referral information into their own record. In this case, two Patient objects are involved. If the consultant simply looks at the referred Patient HealthRecord (and possibly responds to it), then only one Patient object is involved.
HL7 RIM Patient Role (player is a LivingSubject, typically a Person, scoper is an organization, typically the provider's organization).
An invitation is a mechanism for enabling a new ManagedReference. Tolven calls this a Bearer Invitation because the sender or Tolven may not know exactly who the receiver is. In most cases, a Bearer Invitation is not completely open. For example, a Sponsorship Invitation by an employer may insist that all bearers have a certain eMail suffix corresponding to that company). Or that the recipient know a secret.
Sponsor example: A company creates a unique Tolven invitation for each Employee containing a salted digest of the employee number or social security number. (The actual plaintext value is not detectable by anyone including Tolven). To activate the invitation, the bearer would have to know the employee number or SSN or whatever the challenge question was. Meanwhile, the employer has no way of knowing exactly how the employee will use that invitation: A joint, existing Tolven account, a new, individual Tolven account, etc.
Also see Referral.
Limbo, Anonymous Record Target, managedReference.
Consider a consultation scenario: The referrer wants the consultant to look at the current HealthRecord for a patient. This is not an eMail-type scenario: Time may have passed before the consultant sees the record and things may have changed since the referral was initiated. While referrals always follow the same basic flow, in this case, the referring physician, at Valley Hospital, is referring to a physician at University Medical Center (UMC) nearby. Neither the physicians nor their organizations have any formal affiliation.
The referring physician at Valley is a Tolven user (it doesn't matter if Valley as a whole has a Tolven Account or not). The referring physician uses a Tolven wizard to initiate an invitation to the specialist at UMC. The referring physician does not know nor does he care if the consultant has a Tolven account or not (this goes to the essence of bearer invitations). There is no cost to the invitee so there is even less reason for the referrer to care one way or the other. What the referrer does know is the consultant's eMail address. That and the medical CCR data stored in the sender's Health Record for the Patient is all that is needed to initiate the referral.
At this point, Tolven is unable to determine which account should receive the referral and of course privacy concerns prevent Tolven from sending patient information in the eMail message. In fact, sending stale patient data in a message is not what was desired. To explain further, we switch to the consultant's side of this scenario. The Tolven-assisted message sent on behalf of the referrer looks something like this:
From: ron.sachs@ValleyHospital.com To: Wanda.Wilson@umc.edu Dr. Wilson, I've got a patient that I'd like you to look at. The record is at: https://referral.tolven.com/record.jsf?id=E3455671 If you are a Tolven user, you may have to sign-in after clicking this link. Thanks, PS: Tolven never sends patient information via general-purpose eMail. The link above provides a secure means of accessing patient data. Please note that if you are new to Tolven, your eMail address will be verified during account creation. This message is computer-generated at the request of the sender from a template approved by the sender. |
As you can see from the message, no patient information is revealed, and it doesn't matter if the recipient has a Tolven account or not. Ignoring security for a moment, the link supplied references a Tolven data structure called an Invitation. The Invitation has a number of functions but most of all it authorizes a ManagedReference to be created between a HealthRecord (or part of one) in the sender's account and the receiver's Referral account. The Invitation may contain additional challenges in order to activate the ManagedReference. For example, the referrer may require that the email suffix of the authenticated consultant be limited to @umc.edu or may require the recipient to answer a challenge question. However, these additional challenges are not mandatory: Tolven requires the consultant to authenticate through eMail and Tolven will record every access to HealthRecords including this access.
Further, the invitation is likely to have conditions controlling the nature of the ManagedReference. Of primary concern is its revocation, which is usually timed or tied to an event such as when the referring clinician receives the consultation report. And since the consultant will be seeing data as it arrives in the referrer's record, subject to the conditions of the invitation, the consultant will be able to make decisions without, necessarily, having to pester the referrer.
If the consultant is already or becomes a full Tolven user now or at some point, then she can use Tolven to establish her own record for the patient, make submissions to the referring provider's record, or initiate her own referrals. Note: Establishing a HealthRecord in UMC is a separate process covered in SubAccount.
The Invitation may also specify the terms or mechanism of a response. As can be seen in the message, the sender may have specified in the template to call him or respond on-line. What the latter typically means is that the consultant will create a new submission directed back to the referrers HealthRecord for the Patient. The response process is technically nearly identical to the original referral: The consultant is not authorized to directly access and update the referer's HealthRecord and so an Invitation of sorts is sent back to the referrer who, at their discretion, can add the consultant's report into the HealthRecord.
This same mechanism works when referring to a team instead of an individual provider. The eMail would be addressed, say, to dialysis_referrals@umc.edu which is an alias read either by the whole team or someone selected to triage referrals and forward the request to the individual on call. For teams, the ManagedReference behaves differently: A full Tolven account is needed to allow more than one user to share a single Referral account, allowing anyone on the team access to the referral. On the other hand, using free Tolven referral-only Accounts, each team member would have a separate referral account and thus the referrals would not be shareable.
You might wonder why free Referral Accounts cannot be shared by multiple Tolven Users. For a User to invite another User to join an existing account requires a full Tolven account; the same basic process as for a Referral Invitation.
The referral could have requested a response back to a team rather than an individual. The mechanism is the same but the referral might have specified that a response be sent back to:
family_practice_group@valleyhospital.com.
An organization authorized to interact with TolvenAccounts such as for Lab orders and results, in-house or retail pharmacy, etc. Tolven must authenticate participants, typically with a Digital Certificate (this is usually mutual). The means of connection is usually a Web Services and the payload corresponds to a Tolven Document.
Communication with Participants is not unlike communication between consumers and providers. For example, when a lab result arrives, it is stored as a document and sent to the ordering Provider. This person (or a team member) then verifies the result(s) by adding the document to the Patient's health record (and, at the same time, may release it to the patient, potentally as an automatic process).
Sending an order outbound is similar to a Referral. A document is created, added to the patient's health record, and sent to the participant. The one exception being that the communication method is more likely a Web Service than an eMail address, but that is just a configuration detail. Also, the conditions of sending and thus accepting communications will be controlled by the participant but Tolven may be asked to provide the user's credentials, such as DEA number and/or license number for prescriptions.
HL7 RIM: An Organization (Entity) playing the Role of (usually) Licensed Entity. Or, if not, then an Identified Entity. The HL7 RIM system-level Entity is a Device. Thus, Tolven communicates most directly with a Device which belongs to an Organization.
A provider is an organization with a Tolven Account used for the purpose of maintaining eCHRs. Larger providers will have many sub-accounts whereas a small provider may have no sub-accounts at all.
HL7 RIM: An Organization is a type of Entity. A Provider is a role played by some Organizations.
A managed reference has two aspects: The reference may be revocable and it may be private. Revocability is controlled by the owner of the reference. Reference privacy is controlled by either the sender or recipient of the reference. Simply put, the reference is invisible (computationally impossible to determine) by anyone other than party authorized to view it.
A user with special permission relative to a TolvenAccount (no privileges beyond that one account). Can extend invitations to other users to become users of that account. Can also remove users from the account (the user may still participate in other accounts). Technically, a “role” of a user.
Note: Administering an account does not, on its own, allow the administrator to see any health data. This is because administrators (or anyone else other than the owner of the data) do not know the password protecting the data itself. This also means that an administrator will be unable to recover protected data.
Associates a user with a Tolven Account. This linkage may be broken by any user with AccountAdministrator permission for that account. The linkage is established via Invitation (see) from an AccountAdministrator sent to a user or potential user. If a user has more than one UserAccount links when he/she logs in, the user is prompted to select which account to be connected to for that session.
|
||||||||||
| PREV NEXT | FRAMES NO FRAMES | |||||||||