Beginner's Guide to Health Tech
Who Is This For?
This guide is for software engineers interested in building health-tech products who don't have experience with the highly regulated world of health-tech software.
If you already develop healthcare software, you may want to skip to our quickstart guide.
What is an EHR?
EHR stands for "Electronic Health Record." On a practical level, EHR has become a generic term for a software system handling all of the common tasks and workflows associated with delivering clinical care. These may be clinical tasks like recording patient history or documenting clinical encounters, and clinical workflows like ordering laboratory or radiology tests and prescriptions. An EHR also includes non-clinical functionality like insurance validation, credit card processing, appointment scheduling, patient-provider communication; nearly everything that happens within a clinical organization.
Most EHRs are "monolithic." They are inflexible, with tightly coupled back-end functionality and front-end implementation. This makes building new functionality and workflows on top of existing EHRs extremely difficult.
What Is Oystehr?
Oystehr (opens in a new tab) isn't an EHR on its own. Oystehr is a cloud-based service for building health and medical software. These kinds of services are often called headless EHRs. Oystehr provides all the backend functionality of a monolithic EHR via APIs, data models, hosting, and SDKs.
Oystehr drastically reduces the cognitive and technical load necessary to create innovative healthcare software. Even so, being an exceptionally regulated environment, you will need to be familiar with certain concepts and standards.
What is Ottehr?
For some projects, "headless" is exactly where you want to start. You have complete control over the user experience. You may not even need a user interface. But if you would like a reference implementation or an out-of-box solution, Ottehr (opens in a new tab) may be a good option. Ottehr is a lightweight, open-source EHR built on top of Oystehr. It exists as an independent product with its own roadmap, and it is used by clinical and software organizations either as-is or to produce white-labeled products.
Regulatory environment
Even though Oystehr abstracts away a lot of detail around regulatory compliance, it is still necessary to understand a few basics.
HIPAA
HIPAA (opens in a new tab) encompasses a very general set of legal requirements for handling sensitive patient data. Although organizations sometimes advertise themselves as "HIPAA certified," no such certification exists. HIPAA is far less detailed and prescriptive than other health-tech standards, but it is a legal requirement for any software handling medical or patient data. Oystehr is a fully HIPAA-compliant service. In order to store patient data within Oystehr you will need a BAA, a business associate agreement. This is a legal requirement whenever two organizations exchange patient data. Oystehr provides a BAA at no additional charge.
ONC
The Office for the National Coordinator for Health Information Technology (opens in a new tab) is a US-government regulatory organization that operates as a division of the Department of Health and Human Services. It maintains a set of standards used by auditors to formally certify EHRs and health-tech products in a variety of different criteria.
FHIR
Pronounced "fire", FHIR (opens in a new tab) is most importantly a set of data models ("Resources") and APIs for interacting with many different aspects of health data. FHIR is the core data model of Oystehr and you will become very familiar with the FHIR standard as you build applications on Oystehr. It is both the single most important standard for health-tech builders and unfortunately has a steep learning curve. FHIR excels at accounting for every possible clinical use-case, but as a result it is often daunting for newcomers. We'll try to ease you in.
There are multiple versions of FHIR. Oystehr supports R4B and R5. R5 offers substantial improvements for many workflows and use cases; however, it is less widely adopted and hasn't been blessed by the ONC for EHR certifications. If you might need ONC certification of your product, or you want maximum interoperability with other systems, use R4B. If you want the easiest possible path to implementing emerging workflows (e.g. telemedicine), consider R5. Don't agonize too much over the decision, they are quite similar. When in doubt, R4B is the better choice for now.
Let's learn the basics of FHIR by considering the Patient resource (opens in a new tab).
A FHIR "resource" is a little like a Class or Prototype in many programming languages. You can see it contains many attributes:
The cardinality of an attribute ("Card") tells you the minimum and maximum number required. 0 means it can be null. 0..1 means you may have null or at most one. 0..* represents a one-to-many relationship that also allows null. "1..1" means it is a not-null attribute that must have a single value.
Let's skip the UML and XML tabs, and look at the JSON tab. In most cases, including with Oystehr, FHIR resources are transported as JSON objects. If you are working in R5, you will see an R5 Diff tab instead of "R4 Diff." This provides an easy method of understanding changes between FHIR versions.
Because FHIR is so flexible and comprehensive, it is often not obvious how to correctly model even fairly basic workflows. Feel free to ask your FHIR questions in Oystehr's Slack support channel (opens in a new tab) or the public FHIR forum (opens in a new tab).
U.S. Core (USCDI)
Many countries, including the United States, maintain their own set of standards for FHIR implementations. These are called "cores" or more formally in the case of the U.S., the U.S. Core Data for Interoperability (USCDI) (opens in a new tab). The USCDI specifies what versions of FHIR are acceptable for certain purposes, as well as how to implement specific workflows. Because the FHIR spec is very flexible, in the absence of such guidance, different organizations might choose different implementations (in fact they often do anyway!). To help guide the implementation process, US Core specifies how to model many common workflows (for example, how to record blood pressure readings (opens in a new tab)).
X12
Many years ago, before simple, human-readable interchange formats like JSON became the standard for interoperability, EDI formats like "HL7 v2" and X12 were adopted. Because health-tech changes very slowly, they still exist in many places. X12, for example, is still used for exchanging data with payers when processing claims for reimbursement. Here's an example:
ISA*00* *00* *ZZ*SENDERID *ZZ*RECEIVERID *200901*0201*U*00401*000012911*0*T*>~
GS*PO*CUSTOMERID*SUPPLIERID*20020901*0201*12911*X*004010~
ST*850*0001~
BEG*00*SA*L8266355**20020901~
REF*CO*ABC12345~
CSH*N~
DTM*064*20200903~
DTM*063*20200909~
N1*ST*SHIPTO*92*1234567~
PO1*1*108*EA*39*CP*VN*CUSTCODE678~
CTT*1*108~
SE*10*0001~Oystehr abstracts away the details of using X12 for claims processing.
HL7v2
HL7 is the organization that maintains the FHIR standard. So it might be natural to assume that "HL7v2" is an earlier version of FHIR. It's actually "version 2" of an older standard. A funny thing tends to happen with health tech standards. Even though the standards are versioned and regularly incremented, some versions tend to "stick" and some end up skipped entirely by regulatory bodies. HL7v2 is one of those versions that stuck, and has been around for many years. It looks a lot like X12:
MSH|^~\&||.|||199908180016||ADT^A04|ADT.1.1698593|P|2.7
PID|1||000395122||LEVERKUHN^ADRIAN^C||19880517180606|M|||6 66TH AVE NE^^WEIMAR^DL^98052||(157)983-3296|||S||12345678|87654321
NK1|1|TALLIS^THOMAS^C|GRANDFATHER|12914 SPEM ST^ALIUM^IN^98052|(157)883-6176
NK1|2|WEBERN^ANTON|SON|12 STRASSE MUSIK^^VIENNA^AUS^11212|(123)456-7890
IN1|1|PRE2||LIFE PRUDENT BUYER|PO BOX 23523^WELLINGTON^ON^98111|||19601||||||||THOMAS^JAMES^M|F|||||||||||||||||||ZKA535529776If you need to integrate with other health-tech systems, including many older EHRs, you may need to use an HL7v2 feed.
SNOMED, CPT, and ICD
Much of the activity that happens in clinical environments is captured in standardized coding systems. For example, documenting a medical condition (e.g. ICD code: I15.9, "Secondary hypertension, unspecified") performing a procedure (e.g. CPT code: 99397, "established well–patient visit for a patient who is 65 years or older") or entire taxonomies that attempt to create supersets of other coding systems, like SNOMED (opens in a new tab):
For now, simply be aware that as you build health-tech systems you will come in contact with many standardized coding systems.
Next Steps
Now that you have a basic understanding of the regulatory environment and the standards you will be working with, you can move on to the quickstart guide to start building your first health-tech application. If you have any questions, feel free to ask in the Oystehr Slack channel (opens in a new tab) or contact support.