Help
Options
Question
FHIR is a _____ specification?
click to flip
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't know
Question
The FHIR specification defines what?
Remaining cards (204)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
FHIR Session 1
Cert Prep S1
| Question | Answer |
|---|---|
| FHIR is a _____ specification? | Platform |
| The FHIR specification defines what? | a set of capabilities used across the health care process |
| What jurisdictions can FHIR be used in? | All |
| What context(s) can FHIR be used in | Many |
| How many FHIR Modules are there? | 13 |
| What are the M1 Modules? | Foundation |
| What are the M2 Modules? | - Implementer Support - Security & Privacy - Conformance - Terminology - Exchanging |
| What are the M3 Modules? | Administration |
| What are the M4 Modules? | -Clinical - Diagnostics - Medications - Workflow - Financial |
| What are the M5 Modules? | Clinical Reasoning |
| What are the categories of the Modules? | Infrastructure, Content, Reasoning |
| Which module levels are categorized as Infrastructure? | - M1 - M2 |
| Which module levels are categorized as Content? | - M3 - M4 |
| Which module levels are categorized as Reasoning? | M5 |
| Which Modules are in the Infrastructure category? | - Foundation - Implementer Support - Security & Privacy - Conformance - Terminology - Exchanging |
| Which Modules are in the Content category? | - Administration - Clinical - Diagnostics - Medications - Workflow - Financial |
| Which Modules are in the Reasoning category? | Clinical Reasoning |
| What are 3 helpful documentation pages? | - Common Use Cases - Resource Guide - Registry of Implementation Guides |
| What 4 items do all Modules contain? | - Scope & Index - Use Cases - Security & Privacy - Roadmap |
| What is contained in the Module scope and index? | Description of content and index of important content |
| What is contained in the Module use cases? | Guidance for common uses of the module |
| Which module component is a key resource for implementers? | Use Cases |
| What is contained in the Module roadmap? | where module content is in terms of overall progress |
| FHIR stands for? | Fast Healthcare Interoperability Resources |
| Who created FHIR? | HL7 |
| What is FHIR? | a next generation standards framework |
| What standards does FHIR leverage? | latest web: XML, JSON, HTTP, OAuth etc. |
| What is the strong focus of FHIR? | implementation |
| How does FHIR relate to other healthcare standards? | evolutionary development path from v2 and CDA that combines the best features of v2, v3, and CDA |
| How are FHIR solutions built? | assembling resources into working systems. |
| What are the modular components used by FHIR called? | Resources |
| What contexts is FHIR suitable for? | -phone apps - cloud apps - EHR based apps - server communication |
| How does FHIR kickstart development? | There are multiple implementation libraries and many examples |
| Who can use the FHIR specification? | It is free for use with no restrictions |
| Can a base resource be used as is? | Yes, it can. |
| How can a base resource be adapted? | Using a Profile to apply extensions, add terminologies, etc |
| What does the RESTful architecture provide? | seamless exchange of info using messages or documents. and service based architectures |
| FHIR specifications are? | concise and easily understood |
| What is a feature of the FHIR Serialization format? | it is human readable for ease of use by developers |
| FHIR and other healthcare standards (v2, v3, CDA) can? | coexist and leverage each other |
| Central challenge for healthcare standards? | variability due to diverse processes |
| What are profiles used for? | to add more control and meaning (constrain a base resource) |
| Is the FHIR standard Normative? | No, it has Normative portions |
| What is the FHIR Framework based on? | Resources |
| What is a resource? | An instance level representation of some kind of healthcare entity |
| Common features of a resource (5). | - a URL - common metadata - human readable XHTML summary - set of defined data elements - extensibility framework |
| How is a resource represented? | XML, JSON, or RDF |
| Each resource instance consists of (6) things: | - resourceType - id - meta - text - extension - data |
| ResourceType is? | - A required element of a resource instance that specifies the resource being represented |
| What is different about the id element in a resource instance? | - it is always present when a resource is exchanged, except during the create operation. |
| Describe the 'meta' section of a resource instance: | - It is usually present (missing if there is no metadata). - It contains the common use / context data to all resources. - Is managed by the infrastructure. |
| What is in the 'text' section of a resource instance: | XHTML that provides a human readable representation for the resource. |
| Is the 'text' section of a resource required. | No, but it is recommended. |
| What is the 'extension' section of a resource instance? | An optional section that contains one or more extensions to the resource. |
| meta.versionId | changes each time the resource content changes (except profile, security, tag) |
| meta.lastUpdated | changes when meta.versionId changes. generally not supported if meta.versionId is not supported. |
| meta.profile | asserts conformance to a profile. Can be changed as profile / value sets change, or as system rechecks for conformance |
| meta.security | security labels applied to resources. Updated when resource changes or when security sub-system chooses to |
| meta.tag | tags applied to a resource that relate to process and workflow |
| implicit Rules | indicates custom agreement about how resources are used that must be understood in order to safely process. (use is discouraged) |
| Create interaction | POST |
| Read interaction | GET |
| Update interaction | PUT |
| Delete interaction | DELETE |
| Search interaction | GET |
| History interaction | GET |
| Transaction interaction | POST {tx bundle} |
| Operation interaction | GET |
| Why is there variability in FHIR | - different geopolitical jurisdictions - different segments in healthcare |
| What is a resource URL? | It identifies the resource and specifies where it was or can be accessed from. It is optional and is not represented inside the resource, rather it arises in context use. |
| How are common business practices enforced in FHIR | They are not and cannot be. |
| How is variability handled? | Using the extensibility framework (extensions) |
| What is the focus of the Base resource? | general, common use cases |
| What is the FHIR version? | The version of FHIR which is in use |
| What is the record version? | The version that is used to track changes to resources |
| What is the business version? | The version used by humans to understand the version of the content, with a formal publishing cycle, that they are dealing with. |
| How is the FHIR version determined? | Usually fixed by the content |
| What are the (3) levels for the record version | - versioning and metadata is not supported - versioning and versionId meta property supported, with history kept - versioning and versionId meta property supported, with history not kept |
| How are FHIR servers expected to support versioning | There is no requirement to support it. |
| RESTful API - success message range | 2xx |
| RESTful API - error message range | 4xx |
| What (9) base properties are contained in all resources (when fully populated)? | - resourceType - id - meta.versionId - meta.lastUpdated - meta.profile - meta.security - meta.tag - implicitRules - language |
| What is the purpose of meta.profile? | It asserts conformance to a profile |
| When does meta.versionID change? | Each time resource content changes |
| When does meta.lastUpdated change? | When meta.versionID changes |
| When is meta.lastUpdated generally not supported? | When mets.versionID is not supported |
| When can id be missing from the base resource? | When the resource is created |
| When can the resourceType be missing from the base resource? | It is always present |
| What do meta.tag elements relate to? | Process and workflow |
| What are implicitRules? | base resource element that indicates a custom agreement about how resources are used that must be understood to safely process |
| A resource in FHIR is analagous to? | a form |
| FHIR Data is the same as? | Completed resources (instances) |
| What does each resource define? | a small amount of highly focused data |
| What does a collection of resources create? | a useful clinical record |
| User actions are the same as? | resource operations |
| Base resources are? | generic |
| What is the 80/20 rule? | focus on 20% of requirements that satisfy 80% of interoperability needs |
| When is narrative expected? | for most resource instances |
| How can narrative be generated? | from discrete info. may be free form text commentary |
| What are the 4 exchange mechanisms in FHIR? | REST, Documents, Messaging, Services |
| Which is the simplest exchange mechanism? | REST |
| Which exchange mechanism uses the Composition resource? | Documents |
| Which exchange mechanism uses the Message Header resource? | Messaging |
| Which exchange mechanism is typically used by decision support? | Services |
| Which (4) modules are of interest for clinicians? | - Clinical & Care Provision - Diagnostics - Medications - Administrative |
| 2 primary components of FHIR? | Resources & APIs |
| The Resource component of FHIR architecture are considered to be the _____? | Physical Models |
| The APIs component of FHIR architecture are considered to be the _____? | Interface implementations |
| What are the interfaces for interoperating? | APIs |
| Which interfaces are targeted by the FHIR specification? | RESTful interfaces |
| Resource definition | A collection of information modules that define data elements, constraints, and relationships for the 'business objects' most relevant to healthcare. |
| Architectural Framework contents | - verifiable and testable syntax - set of rules and constraints - methods and signatures for FHIR aware APIS - specifications for server implementation (capable of requesting/delivering FHIR business objects) |
| What is meant by the Architectural Principle 'Reuse & Composability'? | This is the 80/20 rule. Focus on 20% or requirements that satisfy 80% of interoperability needs |
| What is meant by the Architectural Principle 'Scalability' | Aligning FHIR APIs to REST architecture. |
| Why do we want stateless transactions? | They reduce memory usage. |
| What is meant by the Architectural Principle 'Performance'? | FHIR resources are lean and suitable for exchange |
| What is meant by the Architectural Principle 'Usability'? | Resources are understood by both technical and non-technical audiences even if JSON/XML syntax not understood. |
| What is meant by the Architectural Principle 'Data Fidelity'? | Strong typing and mechanisms for clinical terminology linkage and validations. XML and JSON can be validated against defined business rules. |
| What is meant by the Architectural Principle 'Implementability'? | Easily understood and readily implemented using industry standards and common markup and data exchange technologies |
| What are the decomposition components? | - Information Model - Constraints - Terminology - Usage |
| In Decomposition, what does the Information Model refer to? | Components related to the creation of FHIR resources - Resource - ElementDefinition - DataType |
| In Decomposition, what does the Constraint Model refer to? | Components related to constraints and validity - ConformanceStatement - Profile |
| In Decomposition, what does terminology refer to? | Components related to Clinical Terminologies and Ontologies - CodeSystem - ValueSet |
| In Decomposition, what does Usage refer to? | Components related to the use of FHIR in a run-time capacity - REST API |
| How many layers are there in the Composition Framework | 6 |
| Layer 1 of the Composition Framework | Foundation |
| Layer 2 of the Composition Framework | Base |
| Layer 3 of the Composition Framework | Clinical |
| Layer 4 of the Composition Framework | Financial |
| Layer 5 of the Composition Framework | Specialized |
| Layer 6 of the Composition Framework | Contextualization |
| Compositional Framework Layer 1 description | foundational resources, often for infrastructural tasks, that are generally not referenced by other resources |
| Compositional Framework Layer 2 description | most commonly used resources. They don't typically reference other resources but are often referred to. They have the highest consistency and rigor as well as the greatest governance |
| Compositional Framework Layer 3 description | Resources that are clinical and common. They can be used by themselves but typically reference layer 2 resources and are contextualized when referenced from layers 3, 4, and 5. |
| Compositional Framework Layer 4 description | Resources that build on clinical and base resources |
| Compositional Framework Layer 5 description | Resources for less common use cases that almost always reference resources in lower layers |
| Compositional Framework Layer 6 description | This layer does not contain resources. The components in this layer extend the framework |
| Purposes (3) of the Composition Framework | - organize resources for navigation and identification - classify resources into categories disseminate across layers to stratify commonness |
| Benefits (4) of Composition Framework | - Organization and manageability of health domains - Identifying commonality - Resource prioritization - Tiered governance levels |
| 3 FHIR interface definitionos | - iServeInstance - iServeType - iServeSystem |
| iServeInstance | methods that perform GET, PUT, DELETE |
| iServeType | methods that get type info or metadata |
| iServeSystem | methods that expose or enable system behaviour |
| What types of transactions are defined in FHIR specification? | Stateless |
| Transaction pattern? | request / response |
| Preconditions for security | - EMR implements needed APIs - EMR implements authentication / authorization - patient authenticated and authorized |
| Resource characteristics | - a common way to be defined and represented - a common set of metadata - a human readable part |
| FHIR modeling approach | compositional |
| Resources that describe how resources are defined and used | - Capability Statement - StructureDefinition |
| What do the FHIR Confluence Pages document? | - development processes - methodology - design decisions |
| Where are formal change requests submitted? | HL7 Jira |
| How can you access HL7 Jira from the specification? | Link at the bottom of every page |
| What is the FHIR online chat called? | Zulip |
| Aside from HL7 Jira, and Zulip, and Confluence pages, where else can you find information or provide feedback? | HL7 Forum and Stack Overflow (there is a tag) |
| How is the FHIR Specification licensed? | Under Creative Commons - "No Rights Reserved" |
| What are the registered trademarks of HL7 with regard to FHIR. (must be followed by circled R) | - HL7 - HEALTH LEVEL SEVEN - FHIR - flame logo |
| Copyright / trademark for FHIR | (C) and (R) to HL7 |
| Who has the right to maintain FHIR? | that remains vested in HL7 |
| FHIR Redistribition | is allowed |
| Derivatives / implementation products and services | can be created (can't claim HL7 endorsement) |
| What liability exists for HL7 and contributors | none accepted |
| How is an altered FHIR specification published? | it is clearly identified as a derivative and not FHIR itself |
| How can a derivative specification redefine what FHIR conformance means. | This is not allowed. |
| What are alternate ways of referring to the FHIR specification? | Using FHIR (R) or the FHIR logo (R) |
| How should FHIR be referenced in a document or presentation? | HL7(R) FHIR(R) Standard. FHIR(R) or FHIR(R) Standard on subsequent pages |
| Draft (Standards Development Definition) | Not complete enough or reviewed enough to be safe for implementation |
| Trial Use (Standards Development Definition) | Well reviewed. Ready for Production. No widespread use as yet. |
| Normative (Standards Development Definition) | Reviewed and implemented in a wide variety of environments. Considered "locked" and subject to inter-version compatibility rules. |
| Informative (Standards Development Definition) | Provided for implementation assistance |
| Deprecated (Standards Development Definition) | Outdated and may be withdrawn in future versions |
| Mixed Normative (Standards Development Definition) | Some Normative resources may have Trial Use elements. Some Normative pages may have Trial Use sections. |
| Purpose of Maturity Levels | To judge how advanced (stable) an artifact is |
| Maturity level 0 | Draft - resource or profile published in the current build |
| FMM1 | previous + - no warnings during build - responsible WG indicates it is substantially complete - FHIR mgmt group approved underlying resource/profile/IG proposal |
| FMM2 | previous + - artifact tested and supports interoperability among at least 3 independently developed systems leveraging most of the scope (>80%) based on at least one of the declared scopes - interoperability results reported to and accepted by FMG |
| Where would an artifact generally be tested | At a Connectathon |
| FMM3 | previous + - artifact verified by WG as meeting Conformance Resource Quality Guidelines - has been subject to a round of formal balloting - has at least 10 distinct implementer comments, from at least 3 orgs, resulting in at least 1 substantial change |
| FMM4 | previous + - artifact tested across scope - published in a formal publication - implemented in multiple prototype projects - responsible WG agrees artifact sufficiently stable to require consultation for non-backward compatible change |
| FMM5 | previous + - artifact published in two formal publication release cycles at FMM1+ - implemented in at least 5 independent Prod systems in more than one country |
| Tested across scope | - FMG signed off on lost of example contexts - for each artifact, either: - reviewed and approved by domain expert for scope area - mapped to existing implemented scope-are-specific standard - tested in an implementation |
| Maturity level | Strong relationship to stability. Higher level, more controls enforced. |
| Release Cycle | 18-24 Months Single Dev version Major cycles concluded by formal ballot (followed by publication) |
| version identification | publication.major.minor.revision |
| version identification - publication | trial use or normative version |
| version identification - major | Increments when a breaking change is made. Resets to 0 on new publication. |
| version identifaction - minor | Increments when official snapshot released. Resets to 0 when major changes Snapshots released approx 6 weeks before HL7 WG meetings |
| version identification - revision | The hash for the GIT version from which the specification is built Changes are made numerous times per day |
| Breaking change | change where the previously conformant applications are no longer conformant to the updated specification |
| Substantive change | changes that introduce new functionality, create new capabilities, but do not render existing application non-conformant. |
| Non-substantive change | Should not cause changes in any conformant application - section renumbering, correcting broken links, fixing typos, providing clarifications etc. |
| current build revision | always .cb |
| 3 ways to determine FHIR version | - fhirVersion in CapabilityStatement, StructureDefinition, or ImplementationGuide - fhirVersion parameter on the MIME-type that applies to the resource - specifying a version specific profile in Resource.meta |
| Forward compatibility | content that is conformant in an old release will remain conformant with future versions. |
| Backward compatibility | instances created against future versions of the specification will interoperate with older versions of the specification. * Not guaranteed by FHIR |
| 5 ways to maximize backwards compatibility | - ignore elements that are unexpected - ignore reference to unrecognized resources - ignore unrecognized codes in req and extensible bindings - ignore unrecognized search criteria - respond to commands on unexpected URLs with appropriate error codes |
| How should a deprecated artifact be handled? | Systems should continue to support but are discouraged from using |
| One strategy for conversion between versions. | use extensions |
| Compatibility rules - resource names - names/paths/meaning of existing elements - minimum cardinalities - immutable value sets - | wont be changed |
| Compatibility rules - optional elements/content | may be added (unless is Modifier) |
| Compatibility rules - descriptions - example and preferred bindings | may change |
| Compatibility rules - data types | will not be removed or changed |
| Compatibility rules - new data types - new operations | may be added |
| Compatibility rules - search criteria | may be added but not removed or renamed |
| Compatibility rules - existing parameters | will not be removed or renamed |
| Compatibility rules - exiting endpoints | will not be removed or renamed nor have expected behaviour changed |
Created by:
xjoaniex