BMXNET 4.0 Developer API
Types
All Types | Classes | Interfaces |
Name | Description | ||||
---|---|---|---|---|---|
Context |
Context interface provides the current status and related events of the
patient/visit context within an application, or the EHR.
| ||||
ContextChangedArgs |
The argument to the ContextChanged method. This event has methods that allow you
to detect which aspects of the context have changed and what the new context is.
| ||||
ContextChangingArgs |
An instance of these args are included with the ContextChanging event and this event
is a CancelEventArgs subclass. The Cancel property being set to True represents the desire
to Veto the change so the patient (and potentially visit) does not change. The Veto can be
overriden by the framework so be prepared for the context to change even if you don't want it
to.
| ||||
Division |
This object represents the RPMS Division.
| ||||
Patient |
The Patient object is a read-only object used for patient context.
| ||||
User |
The user that established the connection to BMX either through the WinFramework dialogs or access/verify codes, or
a user established through attach tho the EHR/VueCentric with the EhrFramework.
The user breaks down into who is it and what can they do with some identify and security key checing. | ||||
Visit |
The visit object is used to determine the current context of the application. The key wrinkle in the visit
class relates to create a common interface for EHR/VueCentric and WinForm applications. The EHR/VueCentric supports
visit stubs by default and the WinFramework does not. If the consumer of the visit object is going to use
it to make changes to RPMS then the visit can not be a stub and must the visit must be created.
Examples
In either EHR or WinForm applications, always check for a stub before you call RPC's to update RPMS. If you
do not, the visit may not have been created on RPMS and the visit id will be null.
|