HL7 Version 3 Basics: RIM to Message Design

Transcription

1 HL7 Version 3 Basics: RIM to Message Design George W. Beeler, Jr. Ph.D. Co-Chair, HL7 Modeling & Methodology Committee Principal, Beeler Consulting LLC woody@beelers.com

2 Interoperability HL7 s mission To provide a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. Specifically, to create flexible, cost effective standards, guidelines, and methodologies to enable healthcare information system interoperability and sharing of electronic health records. (Source: HL7 Mission statement, revised 2001)

3 Interoperability Main Entry: in ter op er a bil i ty Function: noun Date: 1977 : ability of a system (as a weapons system) to use the parts or equipment of another system Source: Merriam-Webster web site interoperability : ability of two or more systems or components to exchange information and to use the information that has been exchanged. Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990] Functional interoperability Semantic interoperability

4 Core requirements for standard exchanges Nouns items we communicate about Typically actions and physical things (persons, places, etc.) Verbs - the essential bindings between nouns An action happens to a person One action causes another A person performs an action Vocabulary & model common definitions Assure common perspective Prescribe the nouns and verbs we can use

5 Observation Class Diagram Normative RIM Release 1 LanguageCommunication languagecode : CE modecode : CE proficiencylevelcode : CE preferenceind : BL Entity classcode : CS determinercode : CS id : SET<II> code : CE quantity : SET<PQ> 0..n 1 name : BAG<EN> desc : ED statuscode : SET<CS> existencetime : IVL<TS> telecom : BAG<TEL> riskcode : CE handlingcode : CE player 0..1 scop er 0..1 Role classcode : CS id : SET<II> playedrole code : CE 0..n negationind : BL addr : BAG<AD> scopedrole telecom : BAG<TEL> 0..n statuscode : SET<CS> effectivetime : IVL<TS> certificatetext : ED quantity : RTO positionnumber : LIST<INT> Participation typecode : CS functioncode : CD 1 0..n contextcontrolcode : CS target inboundlink RoleLink sequencenumber : INT 1 0..n typecode : CS negationind Participation : BL source outboundlink effectivetime : IVL<TS> notetext : ED time : IVL<TS> 1 0..n modecode : CE 0..n awarenesscode : CE signaturecode : CE signaturetext : ED performind : BL substitutionconditioncode : CE ManagedParticipation id : SET<II> statuscode : SET<CS> Act classcode : CS moodcode : CS id : SET<II> code : CD negationind : BL derivationexpr : ST text : ED 1 statuscode : SET<CS> effectivetime : GTS activitytime : GTS availabilitytime : TS prioritycode : SET<CE> confidentialitycode : SET<CE> repeatnumber : IVL<INT> interruptibleind : BL levelcode : CE independentind : BL uncertaintycode : CE reasoncode : SET<CE> languagecode : CE source 1 target 1 ActRelationship typecode : CS inversionind : BL outboundrelationship contextcontrolcode : CS 0..n contextconductionind : BL sequencenumber : INT prioritynumber : INT inboundrelationship pausequantity : PQ checkpointcode : CS 0..n splitcode : CS joincode : CS negationind : BL conjunctioncode : CS localvariablename : ST seperatableind : BL LivingSubject administrativegendercode : CE Organization Employee birthtime : TS Material jobcode : CE Patient addr : BAG<AD> deceasedind : BL formcode : CE jobtitlename : SC confidentialitycode : CE standardindustryclasscode : CE deceasedtime : TS Entity jobclasscode : CE Role veryimportantpersoncode : CE multiplebirthind : BL salarytypecode : CE multiplebirthordernumber : INT salaryquantity : MO LicensedEntity organdonorind : BL hazardexposuretext : ED protectiveequipmenttext : ED recertificationtime : TS Place ManufacturedMaterial mobileind : BL lotnumbertext : ST addr : AD expirationtime : IVL<TS> Access directionstext : ED stabilitytime : IVL<TS> approachsitecode : CD positiontext : ED targetsitecode : CD gpstext : ST gaugequantity : PQ Person addr : BAG<AD> Device NonPersonLivingSubject Container maritalstatuscode : CE manufacturermodelname : SC educationlevelcode : CE straintext : ED softwarename : SC capacityquantity : PQ racecode : SET<CE> genderstatuscode : CE localremotecontrolstatecode : CE heightquantity : PQ disabilitycode : SET<CE> alertlevelcode : CE diameterquantity : PQ livingarrangementcode : CE lastcalibrationtime : TS captypecode : CE religiousaffiliationcode : CE separatortypecode : CE ethnicgroupcode : SET<CE> barrierdeltaquantity : PQ bottomdeltaquantity : PQ PatientEncounter preadmittestind : BL admissionreferralsourcecode : CE lengthofstayquantity : PQ dischargedispositioncode : CE specialcourtesiescode : SET<CE> specialaccommodationcode : SET<CE> acuitylevelcode : CE ControlAct Supply Procedure quantity : PQ methodcode : SET<CE> expectedusetime : IVL<TS> approachsitecode : SET<CD> targetsitecode : SET<CD> WorkingList ownershiplevelcode : CE Diet PublicHealthCase energyquantity : PQ carbohydratequantity : PQ detectionmethodcode : CE transmissionmodecode : CE diseaseimportedcode : CE SubstanceAdministration Account value : ANY routecode : CE InvoiceElement interpretationcode : SET<CE> name : ST approachsitecode : SET<CD> modifiercode : SET<CE> methodcode : SET<CE> balanceamt : MO dosequantity : IVL<PQ> unitquantity : RTO<PQ,PQ> targetsitecode : SET<CD> currencycode : CE ratequantity : IVL<PQ> unitpriceamt : RTO<MO,PQ> interestratequantity : RTO<MO,PQ> dosecheckquantity : SET<RTO> netamt : MO allowedbalancequantity : IVL<MO> maxdosequantity : SET<RTO> factornumber : REAL pointsnumber : REAL Acts FinancialContract paymenttermscode : CE DeviceTask FinancialTransaction parametervalue : LIST<ANY> amt : MO creditexchangeratequantity : REAL DiagnosticImage debitexchangeratequantity : REAL subjectorientationcode : CE 4 Primary Subject Areas 35 Classes 181 Attributes 9 Associations 28 Generalizations

6 Action the focus of health care messaging The reason we want to automate health care data is to be able to document the actions taken to treat a patient: A request or order for a test is an action The report of the test result is an action Creating a diagnosis based on test results is an action Prescribing treatment based on the diagnosis is an action In simple terms, a medical record is a record of each of the individual actions that make up the diagnosis, treatment and care of a patient.

7 Five core concepts of the RIM Every happening is an Act Procedures, observations, medications, supply, registration, etc. Acts are related through an ActRelationship composition, preconditions, revisions, support, etc. Participation defines the context for an Act author, performer, subject, location, etc. The participants are Roles patient, provider, practitioner, specimen, employee etc. Roles are played by Entities persons, organizations, material, places, devices, etc.

8 RIM Core Classes Role Link Act Relationship 0..* 0..* 0..* 0..* 0..* Entity 1 1 plays scopes 0..* Role 0..* Participation 1 0..* 1 Act Organization Living Subject Person Material Place Patient Employee LicensedEntity Access Procedure Observation Patient Enc nt r Substance Adm Supply Referral Financial act Working list Account

9 Is Act sufficient? How can a single act class represent all of the elements of clinical action their definition, request, order, report? Answer: the Act mood code A code specifying whether the Act is an activity that has happened, can happen, is happening, is intended to happen, or is requested/demanded to happen.

10 Principle Act moods definition (DEF) Definition of an act, formerly a master file intent (INT) an intention to plan or perform an act request (RQO) a request or order for a service from a request placer to a request fulfiller promise (PRMS) intent to perform that has the strength of a commitment confirmation (CNF) promise that has been solicited via an order event (EVN) an act that actually happens, includes the documentation (report) of the event Critical concept Mood is not a status code. Each instance of the Act class may have one and only one value for mood Thus, an act in order mood that orders an act in definition mood and results in an Act in event mood are three different acts, related through the act relationship.

11 Mood code example Abstract Act classcode : CS =?? moodcode : CS =?? id : II =?? otherattributes Defines a specific kind of observation ObservationDefinition classcode : CS = OBS moodcode : CS = DEF id : II = 123 otherattributes instantiates Type known Mood abstract Observation classcode : CS = OBS moodcode : CS =?? id : II =?? otherattributes Orders a defined kind of observation to be performed ObservationRequest classcode : CS = OBS moodcode : CS = RQO id : II = O otherattributes fulfills Performs the defined observation to fulfill the order ObservationEvent classcode : CS = OBS moodcode : CS = EVN id : II = 7986 otherattributes

12 RIM Core Classes Role Link Act Relationship 0..* 0..* 0..* 0..* 0..* Entity 1 1 plays scopes 0..* Role 0..* Participation 1 0..* 1 Act Organization Living Subject Person Material Place Patient Employee LicensedEntity Access Procedure Observation Patient Enc nt r Substance Adm Supply Referral Financial act Working list Account

13 How is Version 3 better? Conceptual foundation a single, common reference information model to be used across HL7 Semantic foundation in explicitly defined concept domains drawn from the best terminologies Abstract design methodology that is technologyneutral able to be used with whatever is the technology de jour Maintain a repository (database) of the semantic content to assure a single source, and enable development of support tooling

14 The essence of Version 3 Apply the best practices of software development to developing standards a modelbased methodology Predicate all designs on two semantic foundations a reference information model and a complete, carefully-selected set of terminology domains Require all Version 3 standards to draw from these two common resources Use software-engineering style tools to support the process.

15 The problem Storyboard: A clinician, using a local medical office support system, orders a lab test for one of her patients. The test will be performed on a specimen collected at her office. She will send the specimen by courier, and expects to receive a confirmation that the test will be performed, and a result of the test.

16 What do we need? Act (order) Order Participation Author Role - Physician Entity - Dr. Smith in the MD office Participation Performer Role Laboratory Entity - The lab that will perform the test Participation Subject Role Specimen Participation Record target Role Patient in whose record the result goes Act relationship Definition Act (definition) Ordered Test

17 HL7 Graphic representation Foundation of HL7 modeling is defined in a UML profile, but we use an alternate graphic representation that better represents our sentences Nouns are in square boxes All attributes shown All constraints shown on the diagram Verbs are shown as Arrows linking nouns All attributes shown All constraints shown on the diagram

18 Building our sentences - nouns

19 Building our sentences basis

20 Building our sentences contextual verbs

21 Building our sentences relational verb

22 Demo Example POLB_RM Order Definition Author Performer Subject Record target Physician Laboratory Specimen Patient Ordered Test Test

23 Demo Example POLB_RM Author 3 Physician Order Performer Subject 5 7 Laboratory Specimen Record target 9 Patient Definition 11 Ordered Test Test

24 Demo Example POLB_RM Order Author Physician Performer Laboratory Subject Specimen Record target Patient Definition Ordered test

25 Demo Example POLB_RM Order Author Physician Performer Laboratory Subject Specimen Record target Patient Definition Ordered test

26 Demo Example POLB_RM Order Author Physician Performer Laboratory Subject Specimen Record target Patient Definition Ordered test

27 The Message Type constraints

28 Our example schema

29 The essence of Version 3 A family of specifications Built upon a single model of How we construct our utterances The domain of discourse The attributes used Constructed in a fashion to rapidly develop a comprehensive, fully constrained specification in XML

30 Bringing it together One Reference Model, one set of tools, one process produce The mundane a Common element for patient The complex a specification to communicate annotated ECGs for clinical trials Large, rich sets electronic claims, clinical trial data The esoteric clinical genomics The basics message control (headers) All taken from RIM to schemas, and published with a single set of effective tools