1 / 74

HL7 Patient Record Architecture

HL7 Patient Record Architecture. Tutorial Spring HL7 Meeting April 27, Toronto. Instructors. Liora Alschuler, Co-chair, HL7 SGML/XML SIG, Chair KEG (“Kona” Editorial Group), The Word Electric Bob Dolin, MD, PRA Co-editor, Kaiser Permanente Lloyd Harding, PRA Co-editor, IAAI

geneva
Download Presentation

HL7 Patient Record Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HL7 Patient Record Architecture Tutorial Spring HL7 Meeting April 27, Toronto

  2. Instructors • Liora Alschuler, Co-chair, HL7 SGML/XML SIG, Chair KEG (“Kona” Editorial Group), The Word Electric • Bob Dolin, MD, PRA Co-editor, Kaiser Permanente • Lloyd Harding, PRA Co-editor, IAAI • Jason P. Williams, Oceania Clinical Information Systems

  3. Tutorial Outline • Overview • Origin • Goals & Design Principles • Theory • Practice • Implementing the PRA • Provider perspective • HIMSS • Mapping an H&P • Issues in Implementation

  4. Tutorial Materials • Printed handouts • Floppy disk • Website

  5. Overview • Origin of the PRA • Goals & Design Principles • Theory • Practice

  6. Overview Origin Goal/ DP Theory Practice Implement Issues • Pre-HL7 • Document-based exchange • Value of narrative • Kona and Operation Jumpstart

  7. Overview Origin Goal/ DP Theory Practice Implement Provider HIMSS Map Issues • April, 1996: 1st ad hoc meeting • April–Dec: meet (almost) every month • Oct –Dec: negotiate with HL7 • Jan, 1997: 1st meeting as HL7 SIG • July, 1997: Operation Jumpstart at Kona Mansion, Lake Winnipesaukee, NH drafts “Kona Architecture” • August, 1997: HL7 SGML Mixer • Sept, 1997: Initial presentation to HL7 • Sept, 1998: HL7 adopts XML as V3 msg syntax • Feb. 1999, HL7 HIMSS demo HL7 XML

  8. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues • Purpose: expand EMR to include document-based clinical information • support exchange of documents • support reuse of documents • support longevity through system-independent electronic medical records • Scope: exchange of attested documents • Incremental design and implementation: do simple things first • Local specialization interacting with global generalization • Supports broad spectrum of business needs

  9. Overview Origin Goal/ DP Theory Practice Implement Provider HIMSS Map Issues GOALS (1/2): • Use open standards. • Support exchange of documents between users, including those with different levels of technical sophistication. • Give priority to delivery of patient care. • Enable a wide range of post-exchange processing applications • Promote exchange independent of the underlying transfer or storage mechanism.

  10. Overview Origin Goal/ DP Theory Practice Implement Provider HIMSS Map Issues GOALS (2/2): • Prepare the design reasonably quickly. • Enable policy-makers to control their own information requirements without extension to this specification. • Specification of document types for creation and processing other than for exchange lie outside the scope of this effort.

  11. Overview Origin Goal/ DP Theory Practice Implement Provider HIMSS Map Issues • Design Principles (1/2): • Shall be compatible with XML and the HL7 RIM. • Technical barriers to entry shall be minimized. • The architecture shall specify the document types required for exchange. • The architecture shall establish minimal constraints or requirements on document structure and content required for exchange.

  12. Overview Origin Goal/ DP Theory Practice Implement Issues Design Principles (2/2): • The architecture shall be scalable to accommodate highly granular markup such as highly structured text and coded data. • Document types based on this architecture shall accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies. • Documents types for document creation and processing intended for exchange must map to the exchange architecture.

  13. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues • The central problem of information exchange is the tension between: • In other words, “Why can’t everyone just agree to do things my way?” is not the right question. Local Specialization Global Generalization

  14. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues The right question is: • How can we: • impose minimal constraints on local practice yet... • ensure that senders and receivers can share meaning where meaning is, indeed, shared and can apply common processing applications based on a well-understood semantic?

  15. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues The “arch” in PRA • Taxonomy of document types • Classed by type of document • Classed by degree of granularity of markup

  16. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues • Specifies and allows: • mapping from sender’s local schema to standard exchange schema • mapping between different levels of markup granularity • mapping between domain-specific exchange schemas

  17. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues • Scalable document architecture relates documents in a hierarchy according to the degree of encoding • also relates documents with equivalent granularity of markup but different languages or terms

  18. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues The “arch” in PRA

  19. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues Extending the PRA

  20. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues Extending the PRA

  21. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues Why an “arch” not a DTD? • Local and exchange requirements vary • Authoring and processing requirements vary • Simple inheritance between document types • levels of granularity • language • lateral (domains of clinical practice)

  22. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues Benefits • Information can be encoded at varying levels of specificity and understood at the highest, or most appropriate, level of encoding • Information encoded at varying levels can be analyzed at the highest common level • Where a greater level of specificity is required than what is presented, there may be value in the simpler taxonomic categories. • Diverse, local DTDs for document creation, validation, local processing with minimal constraint for exchange • Common processing applications in exchange context

  23. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues Benefits • (Some) preservation of local markup within exchange document • Scalable wrt DTD complexity • Scalable wrt implementation • Permits added level of abstraction, indirection in exchange model • Not a winner-take-all approach to single exchange model; allows distribution of work, cooperation among standards orgs

  24. Overview Theory Exchange “arch” Why Bennies Practice Implement Issues Benefits • Scalable taxonomy for exchange, indexing, searching, other processing applications • Graduated cost/benefit analysis • Graduated levels of conformance

  25. PRA Header :: Overview Overview Theory Practice Header Body Implement Issues Purpose Enable clinical document exchange across and within institutions. Facilitate clinical document management. Facilitate compilation of an individual's documents into a lifetime EHR. Principles Every HL7 Patient Record Document contains a Patient Record Header. The header contains required information that uniquely identifies and classifies the document, attestation details, event, patient, and practitioner. The PRA Header is not intended to replace and does not preclude use of localized header information or local document management information in either the source or the interchange documents. The PRA Header specifies whether a document is an "original", an "addendum", or a "replacement". Header component "document.parent.id" references the updated document. Unique Identifiers All unique identifiers (components containing ".id") are assigned by the document.originating.system. To the extent that originating system names are globally unique, a concatenation of document.originating.system with any unique identifier in the document header results in a globally unique identifier. All header components that are unique identifiers contain an element "id.value" in their content model. For required identifiers, this subcomponent is required.

  26. Overview Theory Practice Header Body Implement Issues PRA Header :: Overview People involved with a clinical document A person should be included as the value for each appropriate header component, even if the person represents the value for more then one component. Header DTD design principles Header components are mapped to the RIM, and use HL7 data type definitions. (Currently, RIM 0.86 and V2.3 data types.) The following #FIXED attributes are used: HL7.datatype : the HL7 V2.3 data type of the element. RIM.attribute : the corresponding RIM attribute. RIM.version: the RIM version mapped to. domain: the HL7 table where enumerated values are drawn from. Where there is a closed enumerated value list (i.e. HL7 V2.3 data type is "ID - coded values for HL7 tables"), header components are modeled as EMPTY, the set of allowable values are enumerated in the DTD, and the value is conveyed in an attribute named "value" (e.g. document.state, patient.sex). V2.3 data type "IS - Coded values for user-defined tables" is modeled as an HL7 V2.3 "CE - coded element" data type (e.g. document.type, practitioner.role).

  27. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <LevelOne> • <header> • <document>...</document> • <event>...</event> • <patient>...</patient> • <practitioner>...</practitioner> • </header> • <body> • ... • </body> • </LevelOne>

  28. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <document> • <document.creation.date>19990212</document.creation.date> • <document.id> • <id.value>1009</id.value> • </document.id> • <document.originating.system> • <id.value>systemX</id.value> • <organization.name>Global Healthcare, INC</organization.name> • </document.originating.system> • <document.originator.id> • <id.value>24680</id.value> • <family.name>Levin</family.name> • <given.name>Henry</given.name> • <suffix>the 7th</suffix> • <degree>MD</degree> • </document.originator.id> • <document.state value="original"/> • <document.type> • <identifier>11492-6</identifier> • <text>HISTORY AND PHYSICAL</text> • <name.of.coding.system>LN</name.of.coding.system> • </document.type> • </document>

  29. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <document> • <document.creation.date>19990212</document.creation.date> • <document.id> • <id.value>1009</id.value> • </document.id> • <document.originating.system> • <id.value>systemX</id.value> • <organization.name>Global Healthcare, INC</organization.name> • </document.originating.system> • <document.originator.id> • <id.value>24680</id.value> • <family.name>Levin</family.name> • <given.name>Henry</given.name> • <suffix>the 7th</suffix> • <degree>MD</degree> • </document.originator.id> • <document.state value="original"/> • <document.type> • <identifier>11492-6</identifier> • <text>HISTORY AND PHYSICAL</text> • <name.of.coding.system>LN</name.of.coding.system> • </document.type> • </document> <!ENTITY % Time_stamp "( #PCDATA | local.header )*"> (YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]) <!ELEMENT document.creation.date %Time_stamp;> <!ATTLIST document.creation.date %common-atts; HL7.datatype CDATA #FIXED "TS" RIM.attribute CDATA #FIXED "Clinical_document_header.origination_dt">

  30. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <document> • <document.creation.date>19990212</document.creation.date> • <document.id> • <id.value>1009</id.value> • </document.id> • <document.originating.system> • <id.value>systemX</id.value> • <organization.name>Global Healthcare, INC</organization.name> • </document.originating.system> • <document.originator.id> • <id.value>24680</id.value> • <family.name>Levin</family.name> • <given.name>Henry</given.name> • <suffix>the 7th</suffix> • <degree>MD</degree> • </document.originator.id> • <document.state value="original"/> • <document.type> • <identifier>11492-6</identifier> • <text>HISTORY AND PHYSICAL</text> • <name.of.coding.system>LN</name.of.coding.system> • </document.type> • </document> <!ELEMENT document.id %Entity_identifier;> <!ATTLIST document.id %common-atts; HL7.datatype CDATA #FIXED "EI" RIM.attribute CDATA #FIXED "Clinical_document_header.id"> <!ELEMENT document.originating.system %Extended_org_name_and_id;> <!ATTLIST document.originating.system %common-atts; HL7.datatype CDATA #FIXED "XON" RIM.attribute CDATA #FIXED "Patient_service_location.id">

  31. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <document> • <document.creation.date>19990212</document.creation.date> • <document.id> • <id.value>1009</id.value> • </document.id> • <document.originating.system> • <id.value>systemX</id.value> • <organization.name>Global Healthcare, INC</organization.name> • </document.originating.system> • <document.originator.id> • <id.value>24680</id.value> • <family.name>Levin</family.name> • <given.name>Henry</given.name> • <suffix>the 7th</suffix> • <degree>MD</degree> • </document.originator.id> • <document.state value="original"/> • <document.type> • <identifier>11492-6</identifier> • <text>HISTORY AND PHYSICAL</text> • <name.of.coding.system>LN</name.of.coding.system> • </document.type> • </document> <!ENTITY % document.state.table " ( original | addendum | replacement )" > <!ELEMENT document.state EMPTY> <!ATTLIST document.state %common-atts; HL7.datatype CDATA #FIXED "ID.EN" RIM.attribute CDATA #FIXED "" domain CDATA #FIXED "HL7Z001" value %document.state.table; #REQUIRED>

  32. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <document> • <document.creation.date>19990212</document.creation.date> • <document.id> • <id.value>1009</id.value> • </document.id> • <document.originating.system> • <id.value>systemX</id.value> • <organization.name>Global Healthcare, INC</organization.name> • </document.originating.system> • <document.originator.id> • <id.value>24680</id.value> • <family.name>Levin</family.name> • <given.name>Henry</given.name> • <suffix>the 7th</suffix> • <degree>MD</degree> • </document.originator.id> • <document.state value="original"/> • <document.type> • <identifier>11492-6</identifier> • <text>HISTORY AND PHYSICAL</text> • <name.of.coding.system>LN</name.of.coding.system> • </document.type> • </document> <!ENTITY % Coded_element "( identifier?, text?, name.of.coding.system?, alternate.identifier?, alternate.text?, name.of.alternate.coding.system?, local.header* )"> <!ELEMENT document.type %Coded_element;> <!ATTLIST document.type %common-atts; HL7.datatype CDATA #FIXED "IS" RIM.attribute CDATA #FIXED Clinical_document_header.type_cd">

  33. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <header> • <document>...</document> • <event> • <event.id><id.value>1009</id.value></event.id> • <event.date>19990212</event.date> • </event> • <patient> • <patient.id><id.value>P001</id.value></patient.id> • <patient.name> • <family.name>Lantry</family.name> • <given.name>Connie</given.name> • </patient.name> • <patient.date.of.birth>19630613</patient.date.of.birth> • <patient.sex value="female"/> • </patient> • <practitioner> • <practitioner.id> • <id.value>24680</id.value> • </practitioner.id> • <practitioner.role> • <text>ATTENDING PHYSICIAN</text> • <name.of.coding.system>HL70133</name.of.coding.system> • </practitioner.role> • </practitioner> • </header>

  34. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <header> • <document>...</document> • <event> • <event.id><id.value>1009</id.value></event.id> • <event.date>19990212</event.date> • </event> • <patient> • <patient.id><id.value>P001</id.value></patient.id> • <patient.name> • <family.name>Lantry</family.name> • <given.name>Connie</given.name> • </patient.name> • <patient.date.of.birth>19630613</patient.date.of.birth> • <patient.sex value="female"/> • </patient> • <practitioner> • <practitioner.id> • <id.value>24680</id.value> • </practitioner.id> • <practitioner.role> • <text>ATTENDING PHYSICIAN</text> • <name.of.coding.system>HL70133</name.of.coding.system> • </practitioner.role> • </practitioner> • </header>

  35. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft • <header> • <document>...</document> • <event> • <event.id><id.value>1009</id.value></event.id> • <event.date>19990212</event.date> • </event> • <patient> • <patient.id><id.value>P001</id.value></patient.id> • <patient.name> • <family.name>Lantry</family.name> • <given.name>Connie</given.name> • </patient.name> • <patient.date.of.birth>19630613</patient.date.of.birth> • <patient.sex value="female"/> • </patient> • <practitioner> • <practitioner.id> • <id.value>24680</id.value> • </practitioner.id> • <practitioner.role> • <text>ATTENDING PHYSICIAN</text> • <name.of.coding.system>HL70133</name.of.coding.system> • </practitioner.role> • </practitioner> • </header>

  36. Overview Theory Practice Header Body Implement Issues PRA Header :: Current Draft "local.header" provides a slot for local (non-exchange related) markup. The default action for the receiver is to ignore the local.header and its contents. If the sender chooses to replace the default with the value of 'markup' they are informing the receiver that they think the content enclosed in the markup may be useful. There is no requirement that the receiver do anything with the markup and content. descriptor: describes the local header. render: may give indication of how the origin would render the content. <!ELEMENT local.header (#PCDATA | local.header)* > <!ATTLIST local.header ignore (all | markup) "all" descriptor CDATA #IMPLIED render CDATA #IMPLIED %common-atts;>

  37. Overview Theory Practice Header Body Issues PRA Body:: Current Draft Minimal markup • Minimal amount of markup at level one. • Prose structures. • Sections have an optional section.title. • Sections consist of paragraphs, lists, and tables. • Sections can nest.

  38. Overview Theory Practice Header Body Implement Issues PRA Body:: Current Draft • Example of sections with titles and paragraphs. • <LevelOne> • <header>...</header> • <body> • <section> • <section.title>ADMITTING PHYSICAL EXAMINATION</section.title> • <section> • <section.title>GENERAL</section.title> • <paragraph>The blood pressure is 170/88, pulse 80 and regular, and respirations 18. She weighs 240 pounds. </paragraph> • </section> • <section> • <section.title>HEENT</section.title> • <paragraph>Examination of the head is normocephalic. The patient has bilateral carotid bruit. There is no jugular venous distention or lymphadenopathy. </paragraph> • </section> • </section> • </body> • </LevelOne>

  39. Overview Theory Practice Header Body Implement Issues PRA Body:: Current Draft Lists • A list contains zero or more items followed by an optional list. • Items can contain zero or more paragraphs followed by an optional list. • The structure allows nesting of lists.

  40. Overview Theory Practice Header Body Implement Issues PRA Body:: Current Draft Tables • The table captures the structural aspects of multi-dimensional tables and • the content relationships. • Tables contain an optional table.title and one or more fields. • Fields contain a field.title and a mixture of zero or more fields and cells.

  41. Overview Theory Practice Header Body Implement Issues PRA Body:: Current Draft Local.markup • Links are used in a number of elements besides tables. The link element is similar to an HTML link. • Local.markup can be used to indicate to the receiver that this information is not exchange information. The receiver may optionally use the information. • Local.markup includes a descriptor and render attribute.

  42. Overview Theory Practice Header Body Implement Issues PRA Body:: Current Draft Healthcare.code • Healthcare.code should be used to derive medically-related in line items such as coded vocabularies. • Contains attributes to indicate the code and the coding system. • A healthcare.code may apply to non-contiguous text through the use of XML ID/IDREF attributes.

  43. Overview Theory Practice Header Body Implement Issues PRA Body:: Current Draft • <LevelOne> • <header>...</header> • <body> • <section> • <section.title>ADMITTING PHYSICAL EXAMINATION</section.title> • <section> • <section.title>GENERAL</section.title> • <paragraph>The blood pressure is 170/88, pulse 80 and regular, and <healthcare.code identifier="9279-1" preferred.name="RESPIRATORY RATE" name.of.coding.system="LN" local.coding.system=“N”> respirations </healthcare.code> 18. She weighs 240 pounds. </paragraph> • </section> • <section> • <section.title>HEENT</section.title> • <paragraph>Examination of the head is normocephalic. The patient has bilateral<healthcare.code identifier="F-F5480" preferred.name="carotid bruit" name.of.coding.system="SN3" local.coding.system=“N”> carotid bruit </healthcare.code>. There is no jugular venous distention or lymphadenopathy. </paragraph> • </section> • </section> • </body> • </LevelOne>

  44. Overview Theory Practice Implement Issues • Implementing the PRA • Provider perspective • HIMSS • Mapping an H&P

  45. Overview Theory Practice Implement Provider HIMSS Map Issues Provider perspective • Analyze local requirements • Document analysis and DTD creation • Document generation & markup • Document management & processing • Document display & transmission

  46. Overview Theory Practice Implement Provider HIMSS Map Issues

  47. Overview Theory Practice Implement Provider HIMSS Map Issues

  48. Overview Theory Practice Implement Provider HIMSS Map Issues

  49. Overview Theory Practice Implement Provider HIMSS Map Issues

More Related